Summary
Beck opens this part of the book giving a summary of what to expect. He lays out the rhythm of TDD and what the reader will find surprising. There isn't much to summarize here so I'll just quote him.
- Quickly add a test.
- Run all tests and see the new one fail.
- Make a little change.
- Run all tests and see them all succeed.
- Refactor to remove duplication.
The surprises are likely to include
- How each test can cover a small increment of functionality
- How small and ugly the changes can be to make the new tests run
- How often the tests are run
- How many teensy-weensy steps make up the refactorings
Commentary
These seem simple enough and self explanatory. I didn't think I would have any thoughts other than, "Let's start!". But then I remembered how often I've tried to add a test and had no idea what to do.
I don't see:
- How to know what test to write
I think step 0 could be the most important. It would help answer not just what the next test is but how many there are and what they cover. It might help answer what kind of test to write. Which would probably be lead to:
-1. The many kinds of tests and what they cover.
But it's likely that those two steps would require a different book.
Top comments (0)