Test Driven Development

Test-Driven Development

Concept of the skill

TDD is design discipline through the test-writing lens. The unit of work is the red-green-refactor cycle: write one failing test for one increment of behavior (red), write the smallest production change that makes it pass (green), restructure the shape of both code and test while keeping all tests passing (refactor). Each cycle fits in a few minutes; long cycles indicate either insufficient test granularity or production complexity that should be decomposed. The test suite is the design pressure that shapes production code — writing tests first surfaces hard-to-test code at the moment when the underlying design discomfort (hard-to-use, hard-to-compose, hard-to-maintain) is still cheap to correct.

Replaces test-after-implementation with test-driven design pressure. Solves the problem that tests written after the code mirror the implementation rather than the desired behavior — they lock the current shape in place, fragment under refactor, and miss the design feedback that comes only from articulating what a unit should do before writing it. Industrial evidence (Nagappan et al. 2008 at Microsoft and IBM across four teams) shows TDD codebases have 40-90% lower defect density at 15-35% longer initial development time; Erdogmus et al. (2005), Janzen & Saiedian (2008), and Bissi et al. (2016) converge on the same direction. Replaces "tests as regression coverage" with "tests as design pressure that produces regression coverage as a side effect."

Distinct from testing-strategy, which owns the strategic question of what to test, at which level, with what evidence — strategy decides the surface, TDD prescribes the rhythm within it. Distinct from test-doubles-design, which owns mocks/stubs/fakes/spies as constructs — TDD's schools differ on how much test-doubles design matters to the practice (London heavily, Detroit lightly); the two compose. Distinct from eval-driven-development, the LLM analog where the unit of judgment is pass-rate over a sample rather than binary per-test pass/fail — both share the iteration-first-then-implement spirit but the math underneath differs. Distinct from refactor, which owns behavior-preserving structural change as a technique — TDD calls refactor as the third beat of red-green-refactor; refactor owns how to do it without breaking behavior. Distinct from the obra/superpowers TDD workflow skill on skills.sh, which is workflow-shape (process steps); this skill is concept-shape (the discipline's underlying mechanism). TDD is to code design what a piano teacher's metronome is to a student's playing — the rhythm is not the music, but it surfaces every uneven phrase, every rushed measure, every hesitation, in time to correct it before it ossifies into habit. The wrong mental model is that TDD is "writing tests first" as a procedural rule, where the tests are the point and the production code merely satisfies them. They are not the point. Tests are an artifact of doing design with a test-shaped tool; a team that "does TDD" by writing tests first without heeding the design pressure has the artifact without the practice, and will conclude TDD doesn't work because they will see only the cost (slower initial development) without the benefit (better-shaped code with lower defect density). Two adjacent misconceptions: that high coverage is the goal (coverage is a side effect; engineering tests to satisfy a coverage number Goodharts the discipline), and that the school doesn't matter (a practitioner who has not chosen London or Detroit has chosen by accident — the test suite's character, mock-rich vs state-rich, interaction-heavy vs state-heavy, reveals which school is in use whether the team named it or not).

Coverage

The design discipline of writing the test before the production code that satisfies it, using the test-writing pressure to shape the code's design, and applying the red-green-refactor cycle as the unit of work. Covers the cycle structure (red → green → refactor), the design-pressure mechanism that makes TDD a design discipline rather than just a test-first habit, the London/Detroit/Chicago school distinctions (mockist vs classicist, outside-in vs inside-out, interaction vs state), the relationship between TDD and emergent design, the empirical record (Nagappan 2008 at Microsoft/IBM and meta-analyses since), the boundary between TDD and BDD, and the failure modes (skipping refactor, ignoring design pressure, mock-heavy fragile tests, coverage-as-goal Goodharting).

Philosophy of the skill

TDD is design through the test-writing lens. Every test you sit down to write is a moment of design: what is this unit, what does it own, what does it delegate, what does its interface look like from the outside. The discomfort of writing a hard-to-test piece of code is the same discomfort that will eventually arrive as hard-to-use, hard-to-maintain, hard-to-compose code; TDD makes that discomfort visible at the moment when correcting it is cheap.

The tests are not the point. The tests are an artifact of doing design with a test-shaped tool. A team that "does TDD" by writing tests first without heeding the design pressure has the artifact without the practice; they will conclude TDD doesn't work because they will see only the cost (slower initial development) without the benefit (better-shaped code with lower defect density).

The schools matter. London and Detroit produce different code under the same red-green-refactor cycle, because they apply the design pressure to different surfaces. A practitioner who has not chosen a school has chosen by accident, and the test suite's character — interaction-heavy or state-heavy, mock-rich or mock-sparse, outside-in or inside-out — reveals which they chose without knowing.

The Cycle In Detail

Each cycle should fit in a few minutes — long cycles indicate either insufficient test granularity or production complexity that should be decomposed before continuing.

London School vs Detroit School — A Practical Comparison

A practical heuristic: London-school suits services with rich collaboration (microservices, hexagonal architectures); Detroit-school suits state-rich domains (calculators, domain logic, parsers). Hybrid is the working norm.

When TDD Fits

Use TDD when the next behavior can be named before the implementation exists and feedback can arrive quickly enough to shape the code. Do not force it onto exploration where the target behavior is still unknown; spike first, then restart with tests once the behavior is nameable.

Failure Modes and Corrections

The Empirical Record

Multiple controlled studies and one large industrial study converge on a consistent directional finding: TDD codebases often show lower defect density at the cost of longer initial development time. Treat these numbers as evidence boundaries, not guarantees. The results depend on team discipline, cycle size, refactor quality, domain fit, and whether the team actually uses tests as design pressure rather than only as test-first paperwork.

The trade is well-documented. Teams abandoning TDD often do so on the visible-cost side (the time spent writing tests) without measuring the invisible-saving side (defects not encountered, rework not required).

Evaluation State

This public skill is reference-grounded and carries v6 understanding fields (mental_model, purpose, boundary, analogy, misconception), but its dedicated comprehension eval artifact is still planned. Keep eval_artifacts: planned, eval_state: unverified, and routing_eval: absent until a realistic eval suite exists, includes boundary/negative cases, runs in the same change, and produces evidence.

Verification

After applying this skill, verify:

• Every increment of production code is preceded by a failing test that describes the behavior, not the implementation. If code was written before the test, the test is regression coverage, not TDD-born specification.
• Each cycle includes a refactor beat. Cycles that go red → green → next-red are test-first development, not TDD.
• The school being practiced (London / Detroit / hybrid) is intentional, not accidental. The test suite's character (mock-rich vs state-rich) reveals which school is in use.
• When a test is hard to write, the design is examined. Hard-to-test code is the design-pressure signal; ignoring it (with test-only hooks, exposed internals, or stretched test boundaries) defeats the discipline.
• Test names describe behaviors at the unit's natural boundaries — "calculates total with discount applied," not "tests calculateTotal() line 17."
• Coverage is treated as a side effect, not a target. The discipline is the goal; coverage emerges from doing it.
• The cycle's granularity stays small. Cycles that run hours indicate either over-large tests or under-decomposed production code.
• For research/spike work where the target is unclear, exploration is allowed before TDD applies. The discipline is not universally appropriate.

Do NOT Use When

Key Sources

• Beck, K. (2002). Test-Driven Development: By Example. Addison-Wesley. The canonical book on Detroit-school TDD; defines red-green-refactor and the discipline's core form.
• Freeman, S., & Pryce, N. (2009). Growing Object-Oriented Software, Guided by Tests (GOOS). Addison-Wesley. The canonical book on London-school TDD; defines outside-in mock-driven development.
• Nagappan, N., Maximilien, E. M., Bhat, T., & Williams, L. (2008). "Realizing quality improvement through test driven development: results and experiences of four industrial teams". Empirical Software Engineering, 13(3), 289-302. The Microsoft/IBM industrial study showing 40-90% defect-density reduction.
• Erdogmus, H., Morisio, M., & Torchiano, M. (2005). "On the effectiveness of the test-first approach to programming". IEEE Transactions on Software Engineering, 31(3), 226-237. Controlled experiment on TDD's productivity and quality effects.
• Janzen, D., & Saiedian, H. (2008). "Does Test-Driven Development Really Improve Software Design Quality?". IEEE Software, 25(2). Meta-analysis on TDD's effect on code complexity, cohesion, and coupling.
• Bissi, W., Serra Seca Neto, A. G., & Emer, M. C. F. P. (2016). "The effects of test driven development on internal quality, external quality and productivity: A systematic review". Information and Software Technology, 74, 45-54. Systematic review of controlled TDD studies.
• Fowler, M. (2007). "Mocks Aren't Stubs". Practitioner-focused explanation of the London/Detroit school distinction and its consequences.
• North, D. (2006). "Introducing BDD". The origin essay for Behavior-Driven Development as a vocabulary and tooling layer above TDD.

Skill Graph context

Classification

• Subject: quality-assurance
• Public: true
• Domain: quality/testing
• Scope: Use when reasoning about Test-Driven Development as a design discipline rather than a workflow: the red-green-refactor cycle as a feedback loop, the difference between London-school (outside-in, interaction-heavy, mock-driven) and Detroit-school (inside-out, state-heavy, classicist) TDD, the role of TDD as a design tool (how tests pressure code into more decomposable shapes), the connection between TDD and emergent design, the boundary between TDD and prior-test-suites, why TDD's failure mode is not 'no tests' but 'tests that mirror implementation', and the empirical record of TDD's effects on defect density, design quality, and development velocity. Do NOT use for the strategy of what to test at which level (use testing-strategy), the construction of test doubles (use test-doubles-design), the discipline of LLM eval iteration (use eval-driven-development), or general-software process workflow (use the obra/superpowers test-driven-development workflow skill — this skill is the concept-shape complement).

When to use

• explain why writing the test first changes the design of the code under test
• decide between London-school (mocks-as-design) and Detroit-school (state-verification) TDD for a new module
• diagnose why the test suite is fragile under refactor — likely over-mocked interaction tests
• explain why high test coverage with TDD is a side effect, not the goal
• Triggers: should we write tests first, are mocks ruining the design, is TDD worth it, London school vs Detroit school, the tests changed every refactor

Not for

• construct a mock, stub, or spy (use test-doubles-design)
• decide what test levels (unit/integration/e2e) to invest in (use testing-strategy)
• iterate on LLM behavior using an eval suite (use eval-driven-development)

Related skills

• Verify with: refactor, testing-strategy
• Related: eval-driven-development, type-safety, testing-strategy, test-doubles-design, refactor

Concept

• Mental model: |
• Purpose: |
• Boundary: |
• Analogy: TDD is to code design what a piano teacher's metronome is to a student's playing — the rhythm is not the music, but it surfaces every uneven phrase, every rushed measure, every hesitation, in time to correct it before it ossifies into habit.
• Common misconception: |

Grounding

• Mode: universal
• Truth sources: https://martinfowler.com/bliki/TestDrivenDevelopment.html, https://martinfowler.com/articles/mocksArentStubs.html, https://link.springer.com/article/10.1007/s10664-008-9062-z, https://ieeexplore.ieee.org/document/1423994, https://ieeexplore.ieee.org/document/4493089, https://doi.org/10.1016/j.infsof.2016.02.004, https://dannorth.net/introducing-bdd/

Keywords

• test-driven development, TDD, red green refactor, London school, Detroit school, Chicago school, outside-in TDD, inside-out TDD, mockist, classicist