Summary
Red/Green/Refactor describes the three-step rhythm of TDD: a failing test (red) defines desired behaviour, minimal code makes it pass (green), and then the code is cleaned up (refactor) without breaking the tests.
What is Red/Green/Refactor?
The cycle begins with Red: write a test for a small piece of functionality that does not yet exist. The test fails because the code is not implemented—most testing frameworks display this as red in their output.
Green: write the simplest production code that makes the failing test pass. The goal is not elegance but correctness. Once the test passes—the output turns green—the first part of the cycle is complete.
Refactor: now improve the code. Remove duplication, clarify names, simplify logic. The test suite provides a safety net—if any test turns red during refactoring, the developer knows immediately that something broke. After refactoring, all tests should still be green.
This cycle, typically lasting two to ten minutes, keeps development incremental, defects small, and design continuously improving.
Why is Red/Green/Refactor relevant?
- Incremental progress: Small cycles reduce the risk of large, hard-to-debug failures
- Continuous design improvement: The refactor step prevents technical debt from accumulating
- Immediate feedback: A failing test after refactoring pinpoints the exact change that broke behaviour