This kata is a couple of steps up in difficulty from Leap Years. You are designing one main function with several helper functions. You test drive the implementation one helper function at a time. The group learns about this strategy for breaking down a problem into pieces suitable for TDD.
The theme continues on designing testable code.
The topic is overdesign in software. Read the list of statements below. Circle those that are relevant to the topic, and cross out those that are unrelated. Compare your answers with your neighbour.
Starting at a whiteboard, explain the purpose of the Yatzy kata. Read the description to the group, and put the category and scoring rules on a screen they can see. Ask the group if they can see any examples in the description that would make good test cases. There are lots! For example they might find these examples:
When they’ve identified these, ask the group what order they would tackle the examples in. When some consensus arises, note this on the whiteboard. I expect they would want to order by category, for example:
Don’t worry too much about what order they want to do the categories in, although I do suggest you encourage them to tackle ones, twos etc before tackling pair or full house.
Take the navigator role in the mob, rotate the driver. Steer the group towards a design where you have a function for each yatzy category, and some kind of switch statement in the main function that calls them. Each such function is named after the category, takes a list of five integers, returns an integer. You should get at least as far as creating the first of those functions.
Hand over the navigator role to someone in the mob, continuing to code from where you got to. Make sure they continue to work in small steps, implementing function by function and keeping all the tests passing.
In pairs, discuss: