Chapter 2. Beginning TDD
Experience is a hard teacher because she gives the test first, the lesson afterward.
Chinese proverb
Something big airports are generally very good at is using signs. No matter which airport I fly from, I never have to worry about not knowing which way to turn from a corner. Whenever I no longer know which way to walk, I look up and there it is: the sign that says, “Gate 42: continue straight forward.”
It wasn’t like that when I started writing software for a living. There was just one sign outside the terminal building saying, “Good luck.” Figuring out what I should change and ending up with a correct solution was a bit like trying to find your way to the right gate at Heathrow without the hundreds of signs and displays. For software development, test-driven development with its simple rules and guidance is like those signs at the airport, making sure I end up where I need to be—and in time.
We already created a somewhat shallow idea in chapter 1 of what TDD is and talked about the forces in play, such as incremental and evolutionary design, and the “reversed” cycle of development. As we learned in chapter 1, TDD is both a design and programming technique that’s essentially based on the simple rule of only writing production code to fix a failing test. TDD turns the usual design-code-test sequence of activities around into what we call the TDD cycle: test-code-refactor, illustrated in figure 2.1 and reproduced from chapter 1.