Reproduce the bug in a failing test before fixing it
Writing a test that fails for the reported reason before writing the fix proves the defect is understood and the test can detect it, which a test written afterwards proves neither of.
Do this firstEvery change runs the suite before a human looks at it
Write the test, watch it fail, read the failure message, and only then fix the code. The order is the whole control.
Two things fall out that nothing else gives you. The failure message is written while you still have the reproduction in hand, so it says something useful the next time it fires. And you learn immediately if you have misunderstood the bug — a test that passes before you have fixed anything is telling you that you are about to fix the wrong thing.
What the evidence did to this claim
Nothing good, and the honest thing is to show it. The two studies below are the nearest measured work, and both found that test ordering did not affect quality: a controlled experiment reporting no significant difference, and an observational study of professionals concluding that “sequencing, the order in which test and production code are written, had no influence” — what mattered was the granularity of the steps.
Read the scope carefully before concluding anything. Both measure test-first versus test-last in greenfield feature work. This control is about a narrower practice: reproducing a reported defect in a failing test before fixing it, where the test’s purpose is to prove the bug is understood and detectable. Nobody appears to have measured that. The adjacent evidence runs against the general practice, so this page stays contested until someone measures the specific one.
The decoy
A test written straight after the fix. It passes, it looks identical in the diff, and it has never once demonstrated that it can detect the bug it is named for.
Counterevidence
- A Dissection of the Test-Driven Development Process: Does It Really Matter to Test-First or to Test-Last? — II"Sequencing, the order in which test and production code are written, had no influence" on quality or productivity. What did predict outcomes was granularity and uniformity of cycles — suggesting the benefits attributed to test-first come from working in fine, steady steps rather than from the ordering itself.
- On the Effectiveness of the Test-First Approach to Programming — ITest-first students wrote more tests, and writing more tests predicted higher productivity. On quality — the benefit most often claimed — the result was null: "there are no significant quality differences between the two groups", with the test-last group's median quality numerically higher.
What would settle it
Regression-recurrence rates for defects fixed with a demonstrated-failing test versus a written-after test, in one codebase over a long enough window to catch repeats. The data exists in any mature issue tracker; nobody appears to have mined it for this.
Seen in the wild
Anonymised field observation. Illustration, not evidence — these carry no tier and cannot raise one.
A mutation test reported that no mutants survived. It had never checked that its patch applied, so it was reporting on an unmodified program. A negative result requires proof the experiment ran.
Last reviewed 2026-08-19.