Definition
Test-Driven Development (TDD)
Test-driven development is a practice where you write an automated test for a behavior before writing the code that makes it pass. It follows a tight red-green-refactor loop: write a failing test, write the minimum code to pass it, then clean up the design. Tests drive the implementation, producing well-covered, intentionally designed code.
Key takeaways
- Test-driven development (TDD) writes an automated test for a behavior before the code that makes it pass.
- It follows the red-green-refactor loop: write a failing test, write minimum code to pass, then improve the design under the test's safety net.
- Created by Kent Beck as part of Extreme Programming, it produces focused, decoupled designs and a regression net that makes refactoring safe.
- The cost is discipline and a slower start; it's less suited to exploratory or UI-heavy work where the desired behavior isn't yet known.
Developed by Kent Beck in the late 1990s as part of Extreme Programming and formalized in his 2002 book Test-Driven Development: By Example, TDD inverts the usual order. Instead of coding first and testing afterward, you start by writing a small test that specifies the behavior you want — which fails, because the behavior doesn't exist yet.
The cycle has three steps. Red: write a failing test that captures one small requirement. Green: write the simplest code that makes the test pass, even if it's crude. Refactor: with the test as a safety net, improve the design and remove duplication without changing behavior. Each loop is meant to be short — minutes, not hours — and you repeat it one behavior at a time.
The benefits go beyond a test suite. Writing the test first forces you to define the desired behavior and its interface before implementation, producing more focused, decoupled designs and a comprehensive regression net that makes later refactoring safe. The cost is discipline and a slower-feeling start, and TDD is less suited to exploratory or UI-heavy work where the desired behavior isn't yet known. Variants like behavior-driven development push the same idea toward business-readable specifications.
Planoda ties tests to delivery: acceptance criteria on an issue can map to the behaviors a TDD cycle drives out, keeping the definition of done concrete and verifiable.
Related terms
- Pair ProgrammingPair programming is a software development technique where two engineers work together at one workstation: one (the driver) writes the code while the other (the navigator) reviews each line, thinks ahead, and catches issues in real time. The pair swaps roles frequently. It trades some short-term throughput for higher quality, faster learning, and shared knowledge.
- Definition of DoneA definition of done is a shared, explicit checklist of what must be true before any work item counts as complete — code reviewed, tests passing, documentation updated, deployed. It removes ambiguity about the word 'done,' preventing half-finished work from being declared finished and creating a consistent quality bar across the whole team.
- Acceptance CriteriaAcceptance criteria are the specific, testable conditions a work item must satisfy to be considered complete and correct. Written before work starts, they define the boundaries of a feature — what it must do, and how you'll know it works — turning a vague request into a checklist everyone agrees on, so 'done' is verifiable rather than a matter of opinion.
- Technical DebtTechnical debt is the implied future cost of choosing an easier or faster solution now over a better one that takes longer. Like financial debt, it accrues interest: shortcuts in code, architecture, or tests slow every future change until they're repaid through refactoring. Some debt is deliberate and strategic; some is accidental and corrosive.
- Code ReviewCode review is the practice of having one or more engineers examine a change before it merges, checking for correctness, clarity, security, and adherence to conventions. Beyond catching defects, it spreads knowledge across the team, enforces shared standards, and creates a documented rationale for why code looks the way it does — typically conducted on a pull request.