method · engineering · qa · origin: Kent Beck / XP · upd 2026-06-11

Test-driven development TRANSFORMS

Tests stop checking the work and start commissioning it — the spec the inner loop executes against.

What it was for

TDD inverted the order of work — define correct first, then build toward it — and bought design clarity, regression safety, and honest scope. It was always philosophically right and economically awkward: the discipline tax was real, humans dodged it, and the practice spent two decades being admired more than adopted.

The verdict

TRANSFORMS — upward. The economics that made TDD a chore have reversed. In the engine, tests are not how you check the work; they are how you commission it. A failing test handed to the inner loop is machined intent: executable, unambiguous, ungameable by confident prose. The practice moves from engineering hygiene to the team's core act of authorship.

What changes

The red-green-refactor loop redistributes across the two shafts: humans write red, the machine runs green-refactor at speed. Test quality becomes the ceiling on output quality — a vague test strips the mesh exactly the way a vague spec does. And test-writing stops being a junior task; it becomes the senior craft, because whoever writes the tests now decides what the system is.

The strongest objection

Agents can write the tests too, so the discipline collapses into machines grading their own homework. Conceded as a failure mode, not a fate: generation can be delegated, but the decision of what must be true cannot. Let the machine draft tests; never let it own the definition of done.

Related: Code review · Eval-driven development · Pair programming

TEST-DRIVEN DEVELOPMENT
DWG NO: TSE-LDG-TDD
REV: 1.1 · 2026-06-11
SCALE: 1 : N
The Two-Speed Engine · from The Product GuyEN-IN · changelog forthcoming · ratio 1 : N