RedGreenRefactor

Red-green-refactor is a software development practice used to guide design and implementation through test-driven development. It describes a short, repeatable cycle with three steps: red, green, and refactor. In the red step, a new test is written for a desired function or behavior and the test fails. In the green step, the minimum amount of code is written to make the test pass. In the refactor step, the code is cleaned up to improve structure and maintainability without changing its external behavior. The cycle is repeated as new functionality is added.

Origin and context: The technique is closely associated with Kent Beck and the broader practice of test-driven development within agile and Extreme Programming. It is described in Beck’s writings and widely taught as a foundational workflow for TDD, emphasizing small, incremental changes and rapid feedback. The approach is language-agnostic and is used across many programming environments.

Practice and purpose: The red-green-refactor cycle encourages writing tests before code, ensuring that each new feature is driven by tests and has an immediate safety net. The refactor step focuses on design quality, removing duplication, clarifying interfaces, and improving readability while keeping all tests green. This discipline aims to catch defects early and prevent design decay as the codebase evolves.

Variations and considerations: Some teams frame the cycle as red, green, refactor, repeat, or adapt it within their broader TDD workflows. While widely used, it is not a universal solution; effective use requires a solid automated test suite and disciplined refactoring practices. Misuse can lead to brittle tests or overemphasis on unit testing at the expense of design intent.