Chapter 1. The big picture
Figure 1.1. TDD is a technique for improving the software’s internal quality, whereas acceptance TDD helps us keep our product’s external quality on track by giving it the correct features and functionality.
Figure 1.2. Acceptance test-driven development drives implementation of a requirement through a set of automated, executable acceptance tests.
Figure 1.3. TDD turns around the traditional design-code-test sequence. Instead, we test first, then write code, and design afterward.
Figure 1.4. Test-code-refactor is the mantra we test-driven developers like to chant. It describes succinctly what we do, it’s easy to spell, and it sounds cool.
Figure 1.5. How do we know what our interface should be like if we don’t try to use it? We don’t. Writing the test before the code makes us think about our design from the code user’s (the developer’s) perspective, leading to a usable API.
Figure 1.6. With incremental development—building the whole system in small increments—we are never far from an integrated, working code base. This reduces risk, because the inventory of unfinished work remains small. As we’ll learn later on, incremental development also enables effective learning through early feedback based on the customer and developers constantly seeing actual, working software.