Test-Driven Development

Also known as: TDD

practice · computer science · organizing-schema

Red-green-refactor cycle: write failing test, make it pass, then improve design.

Test-Driven Development was articulated by Kent Beck within Extreme Programming and developed in Test-Driven Development: By Example (2002), with deep antecedents including the test-first practices of NASA's Mercury Project (per Beck's research) and Smalltalk testing traditions. The TDD cycle has three phases that practitioners cycle through rapidly: Red (write a failing test for a small unit of new behavior); Green (write the minimum code to make the test pass, even if the implementation is ugly); Refactor (improve the design of both production and test code while keeping all tests passing). The discipline produces a comprehensive automated test suite as a side effect of development, surfaces design issues early through the test-first constraint (testable design and well-decomposed code tend to align), and provides confidence for refactoring and continuous deployment. London School TDD (Steve Freeman, Nat Pryce, in Growing Object-Oriented Software, Guided by Tests) emphasizes outside-in development with mocking; Detroit (Classical) School TDD favors state-based testing with minimal mocking. TDD has substantial impact on subsequent practices — Behavior-Driven Development, Acceptance Test-Driven Development, and continuous-deployment practices all build on TDD foundations.

Originators

Kent Beck (modern formulation); precursors in Smalltalk testing and (per Beck) NASA Mercury practice high

Year / Decade

Late 1990s within XP; 2002 (TDD by Example) high

Primary sources

Beck, K. (2002). Test-Driven Development: By Example, Freeman, S. & Pryce, N. (2009). Growing Object-Oriented Software, Guided by Tests, Hansson, D.H. (2014). 'TDD is Dead. Long Live Testing' (signalvnoise.com) high

Core components

Three-phase cycle: Red (failing test), Green (minimum code to pass), Refactor
Test-first ordering as design constraint
Comprehensive automated test suite as byproduct
London School (mockist, outside-in) vs Detroit/Classical School (state-based, inside-out)
Connection to refactoring discipline
xUnit family of testing frameworks
Distinction from test-after development
Pairs with continuous integration

Primary use case

Software development practice across many languages and domains; foundation for refactoring confidence and continuous deployment; substantial influence on modern software engineering practice even where full XP is not adopted; core practice in software craftsmanship community; foundation for BDD and ATDD extensions.

Common criticisms

Adoption requires substantial discipline that many teams don't sustain
Detroit-vs-London School disagreement reflects real tensions in testing approach
'TDD is dead' debate (David Heinemeier Hansson, 2014) argued TDD damages design and overweights testability
many teams write tests after code while claiming TDD
mocking-heavy London School TDD can produce brittle tests coupled to implementation
effectiveness depends on test design quality — large test suites of poor tests are a liability
works less well for some categories of code (UI, exploratory data analysis, deeply concurrent code)
empirical research on TDD's productivity effects is mixed and methodologically challenging.

Lineage

Child of: Extreme Programming
Siblings: Extreme Programming, YAGNI
Derived from: Extreme Programming