This chapter is interesting and pithy. Firstly, we have a failing test where the error message is not helpful. Kent Beck guides us through defining a
toString method to give us a better test output. I see unhelpful errors like this all the time - they really are giving me nothing, and yet, making such a change to the error output feels like I'm treading on someones toes. This is something to overcome. Helpful messages when our code goes wrong are so useful to the investigating developer; updating them as they're encountered is a great way to leave to codebase in a better state than when you found it.
The process of TDD allows us to preview failing tests and to experience the error messages our tests leave as their legacy, so helpful messages if and when the code breaks are a huge advantage of using TDD.
We're also introduced to a bit of a pickle for the first time, when our code change leaves us stuck in the red, and the safest route out is to undo the change and write another test first.
"The way forward, is sometimes the way back."
Quote from Labyrinth (1986)
This sticking point was an experiment, and Beck points out that if you don't have tests you're forced to spend time thinking through possible scenarios and outcomes before moving forward. The test process here gives us some agility to experiment. We can go back to the last point when the code was green, and let the computer do some theorising on our behalf.
🔎 View my code-along repo at https://github.com/ruthmoog/test-driven-development-by-example
Kent Beck's "Test Driven Development: By Example" was released in 2002. The book aims to explain how to use TDD to write quality code that works.