Test-Driven Development, or TDD, is a way of building software in which testing and design are interwoven with coding. The Agile Alliance glossary describes it as “a style of programming in which three activities are tightly interwoven: coding, testing (in the form of writing unit tests) and design (in the form of refactoring).”
Martin Fowler summarizes TDD as “a technique for building software that guides software development by writing tests,” and notes that it “was developed by Kent Beck in the late 1990’s as part of Extreme Programming.” The cycle has three repeating steps: write a test for the next bit of functionality, write just enough code to make the test pass, then refactor both new and old code so it is well structured.
These three steps are commonly summarized as “Red - Green - Refactor.” Red is the failing test, green is the passing implementation, and refactor is cleaning up the design while the tests keep it honest. Writing the test first forces a developer to decide what the code should do before deciding how it will do it.
Practitioners value TDD for two reasons beyond catching bugs. It drives design, because hard-to-test code is often a sign of a poor structure, and it leaves behind a suite of automated tests that act as a safety net for future changes. Kent Beck laid out the approach in detail in his book “Test-Driven Development: By Example.”