TDD with a list

TDD is perhaps a little easier when someone else has started making the test list for you.

Learning Objectives

Session Outline

Connect: Waterfall phases

Mark the activities on this list that are phases in a Waterfall method:

When people have made their marks, ask them to check their answers against the waterfall model.

Concept: Iterative and incremental

The whole problem is too large to tackle all at once. In Waterfall, you split the work into phases. The purpose of the Analysis phase is to understand the requirements and work out how to decompose the problem. In TDD we still need to do that, but instead of doing it all at once in a phase by itself, we do it a little at a time. A little analysis, design, coding, testing… then iterate.

Making a test list is part of the analysis work. You identify some pieces of the solution that are testable, that you can soon design and build. It helps you to get started. There is no standard format for this, it’s an informal list that probably only you will read. It’s not an artifact to be saved for posterity. Each item on the test list is a reminder of a test you think you might need. A sketch of an example input and expected outcome, or just a name of a scenario.

Every time you complete a TDD cycle you revisit your test list and update it. By doing the design and coding and testing you learn more about the problem and can revisit the analysis.

Concrete: Carry on with TDD

The starting position for this is in the ‘empty_machine’ branch of VendingMachine-Approval-Kata at least in the C version so far.

Conclusions: small steps

Review the code written now. How many tests are crossed off the list? How many new tests did you think of and add to the list? Have you been working in small steps?