How do you distinguish an arrange-phase breakage from a genuine assertion failure?

## The problem A red test tells you something is wrong. It does not, by default, tell you *which* of the three phases is wrong, and the difference matters more than almost anything else about triage. An assertion that fails because the behaviour returned the wrong answer is a product defect. An assertion that fails because the arrange phase silently failed to build the world it promised is a test defect, and every minute spent debugging the product is wasted. The two look identical in the report: the same assertion, the same line, the same "expected X, got Y". ## A concrete case A playlist service has a "recently played" feature. Its tests arrange by seeding play events with timestamps derived from the machine's clock, then act by requesting the recent list, then assert that a seeded track appears. On one build machine the system clock had drifted 3 minutes 42 seconds ahead of the database host, so events seeded as "two minutes ago" landed in the future and were filtered out of every window. The assertion reported an empty list where one track was expected — phrased, in the failure message, as though the recently-played query were broken. The query was fine. The arrange phase had produced a fixture that did not mean what the test thought it meant, and because the failure surfaced in the assert phase, three people read the query code first. On a 27-minute suite where each diagnosis round costs a full run, that misdirection is expensive. ## Techniques that separate the phases **Precondition checks at the end of arrange.** Before acting, state the assumption the test depends on: the seeded event is inside the window, the fixture has 12 tracks, the stand-in is configured. The check is not the test's oracle — it is a claim about setup — and it fails at a line inside the arrange block, which is the whole point. Many teams give these a distinct helper name (`assume`, `precondition`, `require`) so the report distinguishes them from real expectations. **Let setup failures be errors, not failures.** Where the runner distinguishes a test *error* (an exception before or outside the assertions) from a test *failure* (an expectation not met), keep setup work in the place the runner treats as setup, so a broken fixture is reported as an error. Then a dashboard of errors versus failures is a first-cut triage signal for a whole suite: a spike of errors is usually environmental, a spike of failures is usually behavioural. **Keep the act to one captured statement.** If the act is one line and its result is stored, then an exception thrown during the act has a line number that identifies the act, rather than being buried inside an assertion argument. This is the cheapest of the three techniques and the one most often skipped. **Make the assertion message name the actual claim.** "expected [] to have size 1" is weak; "expected the recently-played list for owner 4417 to contain the seeded track" tells the next reader what the test believed, which is exactly what was wrong in the case above. **Make fixture-dependent assumptions explicit rather than implicit.** The clock case is really a test that depended on a fact — the seeder's clock and the query's clock agree — that appeared nowhere in the test. Either control the fact (inject a fixed time into both sides) or check it in arrange. A test whose correctness depends on an unstated environmental fact will eventually be read as a lie about the product. ## The judgement part Not every test deserves precondition checks; they cost lines and they can themselves rot. The rule worth defending in an interview is proportionality: add them where the arrange phase is *indirect* — data seeded through another service, state built by a helper the test does not own, anything time-dependent — and skip them where arrange is three literal values you can read. The failure you are protecting against is not "setup can break"; it is "setup can break in a way that reads as a product defect". The second judgement call is where to invest when a phase-confusion incident happens. The tempting fix is to harden the one test. The better fix is usually to attack the class: control the clock for the whole suite, or make the seeding helper itself fail loudly when it cannot honour the timestamp it was asked for. One helper that refuses to produce a nonsense fixture protects every test that uses it, which on a large suite is a much better return than a guard in one file. ```pseudocode # arrange fixedNow = timestamp("2026-04-11T09:15:00Z") clock.freezeAt(fixedNow) seedPlayEvent(ownerId = 4417, trackId = 881, at = fixedNow.minusMinutes(2)) precondition(recentWindowContains(fixedNow.minusMinutes(2))) # fails inside arrange, not assert # act recent = playlistService.recentlyPlayed(ownerId = 4417) # assert expect(recent.trackIds).toContain(881) ```