How does the order of tests affect the design of software?
Exercise:
- Write a bunch of plausible unit test descriptions.
- Slice them into strips and put them in a hat.
- Repeat until the hat is empty:
- Pull tests one at a time from a hat.
- Write the indicated test
- Write the code to make the last test pass, TDD style.
- If you absolutely must create a prerequisite test, do so.
- Refactor as you go.
- Set aside your implementation, shuffle the tests back into the hat, and repeat once or twice.
Exercise ideas:
- spreadsheet (domain objects, parsing, representation of storage),
- auction sniper (from Freeman and Pryce’s Growing Object-Oriented Software),
- video rental store (from Fowler et al’s Refactoring),
- currency (from Beck’s Test-Driven Development),
Sample Tests for a Spreadsheet:
- New sheet is empty
- Inserting into a sheet stores a value
- Numeric cells are formatted as numbers
- Cells retain literal values (for editing) Ex: 007 is edited as 007 but displays as 7.
- Cells starting with = are formulas.
- Constant formula Ex. =7
- Parentheses in formulas
- Multiplication in formulas
- Addition in formulas
- Precedence in formulas
Reflection Points:
- Did you encode your tests the same each time?
- Did the solutions come out basically the same? Why or why not?
- Did you see alternative solution paths when you went through again?
Source:
Bill Wake, 2010. Inspired by "Scenes From a Hat" in improv.