What is test-first development, and how does it differ from writing tests after the code?

## The claim in one line Test-first development is the practice of writing an executable test for a behaviour **before** writing the production code that provides it. The whole content of the idea is in the ordering, and everything interesting follows from one fact: at the instant you write the test, there is no implementation to consult. ## What you have when the code does not exist When you sit down to write the first test for a new behaviour, the only inputs you have are the requirement, whatever examples came with it, and your own understanding. You cannot copy a method name off the screen, you cannot read a branch to see which inputs matter, and you cannot look up what the operation returns. You have to *decide* all of that and write it down as a call you would like to make. That is why the exercise is a design activity as much as a verification one. The test becomes the first client of an interface that does not exist, and everything a client cares about — the name, the arguments, the shape of the result, how a failure is reported — must be settled before a line of the implementation is typed. The result is a description of the behaviour written from the outside, by someone who wants to use it. ## What test-after gives you instead In test-after work the sequence is reversed: the code is written, then cases are chosen for it. The cases are not chosen in a vacuum. The implementation is on the screen, so the tests tend to walk its branches, adopt its vocabulary, and stop where its structure stops. This is efficient — it is often the fastest route to a covered line — but it produces **confirmation**: evidence that the code does what it does. A requirement the code never implemented is unlikely to grow a test, because nothing on the screen suggests it. There are also structural consequences. If the code was written without a caller in mind, it may have no seam a test can reach: state hidden behind a construction that also opens a connection, a result reported only through a side effect, or a wide constructor that must be satisfied before anything can be exercised. In test-after work the usual response is to reach for heavier machinery to get at the code. In test-first work that awkwardness shows up before the code exists, when it is still free to change, because you feel it while writing the call. ## The honest comparison It is worth being precise about what test-first does and does not claim. - **It is not a coverage technique.** A disciplined test-after suite can reach the same lines. Coverage is a poor way to tell the two apart. - **It is not proof of correctness.** A test written first is still only as good as the examples you thought of. - **It does change what you learn, and when.** Ambiguity surfaces as an assertion you cannot write: if you do not know what the operation should return for a given input, you cannot finish the line, and you go and find out before the code encodes a guess. - **The empirical evidence is genuinely contested.** Studies of test-first versus test-after report mixed effects on defect density and effort, and reviews disagree about how much of any benefit comes from the ordering rather than from writing small tests at all. Claiming a specific measured improvement is a weak answer; describing the mechanism honestly is a strong one. ## Where the order is not negotiable Some tests can only be written after the code, and that is not a failure of discipline. Characterisation tests for existing code with no specification are written against what the system already does, precisely because the current behaviour *is* the thing being pinned down. The reverse case is a good illustration of the rule: a reported bug is ideal test-first material, because the report supplies a concrete example and the failing test proves you have reproduced it before anything is repaired. ## What an interviewer is listening for Weak answers say test-first "gives you better coverage" or "makes sure the code works". Both are available from test-after. Strong answers name the asymmetry: the test written first is a **specification** produced by the first user of an interface, and the test written afterwards is largely a **confirmation** produced by its author reading their own code. The practical payoff is that requirement gaps, unusable interfaces and unreachable state are discovered at the cheapest possible moment — before there is any code to rework.