TDD
The practice is attributed to Kent Beck, who described it as a core part of Extreme Programming (1999) and developed it in detail in his book Test-Driven Development: By Example (2003). Beck described TDD as a way to produce simple designs and inspire trust in the code.
The red-green-refactor cycle
The TDD cycle is usually described with three colors:
- Red: write a test that fails because the functionality does not exist yet. The failing (red) test is the starting point: it defines what the code must do.
- Green: write the minimum code needed to make the test pass. Only the minimum code: nothing more, even if it looks "ugly" or provisional.
- Refactor: improve the internal structure of the code without changing its external behavior. The tests ensure that the refactoring has not broken anything.
This cycle lasts minutes, not hours. The discipline of staying in short cycles is what makes TDD effective.
What TDD brings
- Test coverage from the start: because tests are written before the code, every piece of functionality has its test from day one. There is no code without a test.
- Emergent design: writing the test before implementing forces you to think about how the code will be used (its interface) before thinking about how it will work internally. This tends to produce simpler, more decoupled designs.
- Safe refactoring: with a complete test suite, the team can refactor and still trust the code. If something breaks, the tests detect it immediately.
- Reduced technical debt: the red-green-refactor cycle builds continuous improvement of the code into the normal development process, rather than treating it as a separate task that "will get done when there's time."
- Executable documentation: the tests describe the expected behavior of the system in a precise and verifiable way. They are a form of documentation that cannot become outdated: if the code changes, the tests detect it.
Relationship with BDD
Behavior-Driven Development (BDD) is an extension of TDD that uses a more expressive language (such as Gherkin: Given / When / Then) to write tests so that they are also understandable to non-technical people. Acceptance criteria written in BDD format are directly executable as tests. TDD and BDD are complementary: TDD applies at the unit level, BDD at the system behavior level.
TDD with AI tools
Generative AI is changing how teams apply TDD in practice:
- Assisted test generation: code assistants (GitHub Copilot, Cursor) can suggest unit tests based on the description of a function. This speeds up writing tests for existing code, although it does not strictly follow the TDD order.
- TDD with AI as a pair: some teams use AI to generate the code that passes a test already written by the developer, thus maintaining the red-green-refactor cycle with assistance.
The greatest risk of using AI in TDD is reversing the cycle: having the AI generate the code first and the tests afterward, as verification rather than as specification. This eliminates the design benefit that TDD provides: writing the test first forces you to think about the expected behavior before thinking about the implementation. With AI generating the code first, that upfront thinking disappears and the code tends to be more complex and tightly coupled.
Common mistake
Applying TDD only to new features and not to bug fixing. A bug in production is a missing test: the incorrect behavior was not covered. The recommended practice is to first write a test that reproduces the bug, verify that it fails (red), fix the code until it passes (green), and then refactor. This ensures that the bug will not happen again without being detected.
References
- Beck, Kent. (2003). Test-Driven Development: By Example. Addison-Wesley.
- Beck, Kent; Fowler, Martin. (1999). Planning Extreme Programming. Addison-Wesley.
See also
Want to advance in agility? You can search for course and exam calls, or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.