Test-Driven Development (TDD)

Test-Driven Development (TDD) is a programming practice in which a developer writes a small automated test for the next piece of behavior before writing the code that makes it pass, then improves the code's design. Repeated in short cycles, it produces software that is covered by tests from the start and shaped around how it will be used.

How Test-Driven Development Works

Kent Beck developed TDD as part of Extreme Programming in the late 1990s and described it in his 2003 book Test-Driven Development: By Example. The cycle is often summarized as red, green, refactor:

1. Red: write one test for a small behavior that does not exist yet, and run it to see it fail.
2. Green: write the simplest code that makes the test pass.
3. Refactor: clean up the new and existing code while keeping all tests passing.

Many practitioners begin by listing the test cases they expect to need, then work through them one at a time. Martin Fowler notes that the most common mistake is skipping the third step: the tests pass, but the code grows messy because nobody refactors.

Why Test-Driven Development Matters

Writing the test first forces a developer to decide what the code should do, and how it will be called, before deciding how it works. That tends to produce smaller, more focused units and a suite of fast tests that makes later changes safer. Teams that adopt TDD often report fewer defects, at the cost of some extra effort up front.

TDD has gained new relevance with AI-assisted development. A test written from the acceptance criteria gives an AI coding agent an unambiguous, executable target, and a failing test is a clear signal when generated code drifts from what was asked. It applies the same principle as spec-driven development: define the expected behavior first, then let implementation follow. Structuring backlogs for AI coding agents shows how to break requirements into small, testable tickets that suit this workflow.

Test-Driven Development Example

A developer needs a function that calculates shipping cost. She writes a test: orders under $50 cost $5 to ship. It fails, because the function does not exist. She writes the function to return 5, and the test passes. Next test: orders of $50 or more ship free. She adds a condition, the test passes, and she refactors the threshold into a named constant. A third test covers international orders. After a few cycles the function is complete, and every rule it implements is documented by a test.

TDD vs. Writing Tests After the Code

Both approaches end with automated tests, but the order changes the result. Tests written afterward tend to confirm what the code already does, and gaps are easy to miss. In TDD, the test defines the behavior and drives the design, so untested code is rare. TDD also differs from behavior-driven development (BDD), which grew out of it and describes behavior in business-readable language.