Main idea

Writing the test first and the code after inverts the usual order, but the point is not in the order. The test describes the what — here is the expected behavior, here is what must stay true. The code describes the how. The first is therefore a piece of the specification, written in a language the machine can evaluate.

What this changes shows up over time. The code will be refactored, it will meet new data, other features will grow up around it. The expected behavior, for its part, is fixed somewhere other than in the memory of whoever implemented it: if it is broken, the test breaks, ideally on the developer's machine or in QA rather than in production.

TDD does not eliminate defects, does not replace product thinking, and does not turn a bad specification into a good product. It does one thing, and it is an uncommon one: it makes part of the quality verifiable before the code exists.

Why it matters

This takes the discipline out of the register of technical hygiene. A test written beforehand is a specification artifact, and therefore a place where product and development can agree on a behavior — which a prose document does not allow, not being evaluable.

It also shifts the cost of tests: written after, they record what the code does; written before, they constrain what it will have to do.

Nuances and limits

The formalizable part is narrow. A test says a behavior is met, never that it was the right behavior to aim for — the portion of quality that falls to product judgment remains whole.

And the discipline presupposes being able to state the expected behavior. Faced with an overly vague specification, writing the test first clarifies nothing: it freezes the ambiguity instead of settling it.

Open questions

• What share of a feature's expected behaviors is really expressible as a test, and what becomes of the share that is not?