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) ...
Get Beautiful Testing now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.