Also known as: test-driven development "TDD"
Test-driven development (TDD) flips the usual order of work: you write a failing test first, then write just enough code to make it pass, then refactor — the rhythm known as “red, green, refactor.”1
The cycle
TDD proceeds in tight loops, popularized by Kent Beck:1
- Red — write a small test for behavior that doesn’t exist yet, and watch it fail. A test that passes before you write the code is testing nothing, so the failure is proof the test is real.
- Green — write the simplest code that makes the test pass, resisting the urge to build more than the test demands.
- Refactor — with a green suite as a safety net, clean up the code — refactoring toward better names and structure without changing behavior, confident any regression turns the suite red.
Then repeat for the next slice of behavior.
Why it helps
Writing the test first forces you to clarify what the code should do — its contract and edge cases — before deciding how to build it, which tends to produce simpler, more testable designs. The discipline also guarantees that every piece of code is covered by a test that genuinely exercises it, and it pairs naturally with continuous CI/CD since the suite is always meant to be green.
In practice
TDD is most associated with unit tests but the same test-first rhythm applies to integration and end-to-end levels, and it often relies on mocking to isolate the unit under test. It is a valuable discipline rather than a mandate — even teams that don’t follow it strictly benefit from specifying behavior up front. Note that the code coverage it produces is a by-product, not the goal: well-asserted tests matter more than the number.
Sources
-
Test-driven development — Wikipedia, for the red-green-refactor cycle and Kent Beck’s role in popularizing it. ↩ ↩2