When is test-driven development the wrong tool for the work in front of you?

### The preconditions a cycle needs A red-green-refactor cycle needs two things, and both are easy to state: 1. **You can name the expected result before you write the code.** The failing test is a specification. If you cannot write the assertion, you do not yet have a specification — you have a question. 2. **You get an answer in seconds.** The cycle is a feedback loop; at ten minutes per run it stops being a loop and becomes a batch process, and people stop taking the steps small. Almost every "TDD does not fit here" case is one of these two preconditions failing. That framing is more useful in an interview than a list, because it tells you what to do next: restore the missing precondition, or accept that a different technique owns this piece of work. ### Where the first precondition fails **Exploratory spikes.** You are not building a feature, you are answering a question — can this library do the thing, what shape does that response actually have, is this approach fast enough. The output of a spike is *knowledge*, not code. Driving it with tests is expensive and pointless, because you cannot assert on an answer you are trying to discover. The discipline is: timebox it, write it as roughly as you like, and **throw it away**. Then drive the real implementation with tests, using what you learned to write the assertion you could not write before. The failure mode is not doing the spike; it is keeping the spike code once it works, at which point untested exploratory code has become the feature. **Unfamiliar external interfaces.** You do not know what the other side returns, so any test you write encodes your guess. Probe first, then encode the observed behaviour as a test of your own adapter around it. **Work whose oracle is a human.** Visual layout, wording, the feel of an interaction. There is no assertion that says "this looks right". Automate the parts that do have oracles and leave the judgement to a person. ### Where the second precondition fails **Performance and capacity work.** The expected result is a distribution, not a value. A test that asserts a hard threshold on a measured duration flips between pass and fail without any code change, and a suite that cries wolf is worse than no suite. Measure with the tools built for measurement, hold the numbers as trend data, and reserve assertions for the coarse regressions you would actually act on. **Long feedback loops.** Anything where the smallest honest verification takes minutes — a full environment provisioning, an end-to-end flow through several systems. TDD is not banned there, but the cycle you run is a different, slower one, and the fine-grained driving happens at a level where the loop is fast. ### A worked example A four-person team on a document e-signing flow needed to know whether a third-party signing service returned per-signer completion times or only an envelope-level timestamp. That is a spike: two hours timeboxed, one throwaway script, question answered. What they then drove with tests was their own fee-splitting logic — where the expected result was perfectly statable in advance, and where a currency-rounding drift of two hundredths per envelope was exactly the kind of defect a before-the-code assertion catches. Mixing those two pieces of work under one policy would have been wrong in both directions: tests around the spike would have tested their own guesses, and a spike around the fee logic would have shipped arithmetic nobody had specified. ### The honest caveats Say plainly that the empirical evidence for the practice is contested: studies disagree on whether it reduces defect density, and the design-quality claims are largely experience reports rather than settled measurement. That does not make it a bad default; it makes confident numbers a red flag. Say equally plainly that "this does not fit" is the most abused sentence in this area. The distinguishing move is that a real exception is **named, timeboxed and has a re-entry point** — "we spike until Thursday, then the real implementation is driven normally" — while an abused one is a standing exemption for a whole subsystem. Concurrency, data transformation and anything described as "too dynamic" are usually not exceptions; they are areas where the assertion is harder to write and therefore more valuable once written. ### What good sounds like A strong answer starts from preconditions rather than a list of forbidden categories, gives one or two concrete cases with the discipline attached (timebox, throw away, then drive), refuses to turn an exception into a policy, and is candid that the evidence base is mixed. A weak answer either insists the practice applies everywhere without exception or treats one awkward area as licence to abandon it wholesale.