Make a test list

In agile, Big Design Up Front (BDUF) is something to be avoided, but that doesn’t mean we don’t do any design at all. Before starting to code with TDD it really helps to spend a few minutes on Little Design Up Front. Part of that is making a list of test cases we will work on.

Session Outline

5 min connect: what to do before you start coding?
10 min concept: Test List
30 min do: Mars Rover
10 min reflect: Correlate test list with TDD cycles

Connect

Ask people to review these options. Ask them to choose an option and read the consequences.

Concept: Test List

Before writing your first test, you should do a little analysis and identify scenarios that you’ll want to make into test cases. Remind people of the test lists you used for previous katas you did in other sessions. When you have reviewed two or three test lists, ask them what the characteristics are for a good test list. You’re looking for things like:

Each case has example input and expected result
A rule or a name to describe each case
Not too many cases, you will add to the list when you start programming

Write these characteristics up on a whiteboard.

Concrete: Write test lists

Ask them to work in pairs to come up with a test list.

Give them a requirements document to work from, like MarsRover.
After they have had time to read it, ask if there are any questions about the requirements. Take the role of business expert and answer their questions.
Ask them to write a list of 4-6 test case ideas, give them 5-10 minutes
Ask them to show their list to another pair and discuss if it has the characteristics identified earlier.
Spend a few more minutes improving the list in pairs

Conclusions: make a common list

Synthesize all the suggestions into a single list. Perhaps use dot voting to choose the top 3 suggestions out of all the lists. With that as a starting point, ask people to take turns to suggest one improvement or addition to the list.

Repeat with a second problem if there is time, for example Fractions or MontyHall.