Beautiful Testing

Test-Driven Development

The remainder of this chapter focuses specifically on automated test-driven development (TDD) as a means to facilitate frequent delivery of running, tested features within a small release. Quality is intensely proactive and grounded in business value. Table 14-1 illustrates a summary of the TDD red-green-refactor cycle.^[67]

Table 14-1. Simplified TDD process (red-green-refactor)

	Author	Developer
Red	1. Create Example
	2. Execute Example
		3. Execute Example
		4. Create unit tests
		5. Execute unit tests
Green		6. Write system code
		7. Execute unit tests
		8. Execute Example
	9. Execute Example
Refactor		10. Refactor system code
		11. Execute Example and unit tests

Red (steps 1–5)

One or more automated functional tests (Examples) define the completion criteria for a user story. The reference to “red” indicates that the Example fails when executed because the relevant system code does not exist yet. Unit tests are written to drive the detailed design and implementation of the code. Unit tests also fail at this point.

Green (steps 6–9)

Developers focus on writing the system code needed to make each unit test pass. Tests are run frequently at this stage to provide feedback on their progress. The reference to “green” indicates that the unit test passes when the relevant system code is in place. Examples pass when all related unit tests pass. At this point, another Example can be introduced, or technical debt can be paid down through refactoring.

Refactor (steps 10–11)

At any stable point—i.e., ...