You cannot write the assertion for a new feature's first test. What does that tell you, and what do you do?

## What a blocked assertion actually is In test-first work you build a concrete case — a specific input, a specific state — and then have to write down what correct looks like for it. The thing that says whether observed behaviour is right is the **oracle**. When you cannot finish the assertion line, you have not hit a testing problem; you have discovered that the oracle for this case does not exist yet. Somebody was going to have to decide it. The only question is whether they decide it consciously now, or whether an implementer decides it by accident and the decision is discovered in production. ## The two flavours, and they need different responses **The requirement is silent.** The specification simply never addressed this input. Consider a fleet telematics ingest whose nightly rollup summarises the previous day per device. The written requirement covers readings arriving in order. You write the case where a device reports the same position twice with identical timestamps — and stop, because "total distance" for a duplicate is undefined. Should the duplicate be counted, dropped, or should the whole device-day be quarantined? Nothing in the requirement decides it, and each answer is defensible. **The requirement is stated in terms nothing observable corresponds to.** The stated behaviour is real but no assertable outcome has been named. "The nightly run must not exhaust resources" is the classic shape: a rollup budgeted at 6 h 12 m has previously fallen over holding 1,438 device buffers open at once, so the ask is genuine — but *exhaust* is not a value anything returns. Here the work is to choose the observable that stands for it: that the ingest holds at most a bounded number of open buffers, that a bounded queue of 4,096 readings refuses the 4,097th with a defined outcome rather than growing, that the run reports a high-water mark you can assert against a ceiling. Once an observable exists, the assertion writes itself. ## What to do, in order 1. **Stop, and name the case precisely.** "Two readings with identical device id and identical capture timestamp" is actionable. "Duplicates are unclear" is not. 2. **Bring candidate answers, not an open question.** Two or three options with their consequences convert a vague conversation with a product owner or domain expert into a decision that takes minutes. 3. **Encode the decision, visibly.** The assertion carries it, and the test name states it in words, so the next reader learns the rule without opening the requirement. 4. **If the decision cannot be had now, keep the gap visible.** Move to cases that *are* decided and leave the undecided one explicitly pending with a note naming who owes the answer. A pending case is a tracked question; a guessed assertion is an untracked one. 5. **Never resolve it by writing the code first.** Implementing and then asserting whatever comes out is the failure mode this whole signal exists to prevent — the code silently becomes the specification, and the decision is never reviewed by anyone who could have made it differently. ## Why this is a senior question Juniors usually experience the blocked assertion as being stuck and reach for the fastest unblock: guess a value, or implement and then read the answer off the result. Both destroy the signal. The senior move is recognising the block as a finding, and being socially willing to interrupt a coding task to get a decision. Doing that well is mostly about arriving with candidates: the difference between "what should duplicates do?" and "we can count them, drop them, or quarantine the device-day — dropping is cheapest and loses a real distance if a device legitimately re-sends; which do you want?" is the difference between a week of ambiguity and a two-minute answer. ## Related judgement calls Sometimes the honest answer is that the case cannot happen. Then say so explicitly rather than leaving it undecided: assert the refusal, or record the impossibility where the next person will read it. And sometimes the block reveals that the case is not one behaviour but two — a duplicate from a device retrying is not the same event as a duplicate from a replayed batch, and once separated each has an obvious expected result. Splitting a case whose oracle is ambiguous is often the quickest route to an assertion you can actually write. ## The distilled point An assertion you cannot write is not friction; it is the requirements defect the practice is best at finding, delivered at the cheapest moment. The strong answer treats it as information, routes it to whoever owns the behaviour, and makes sure the resolution ends up in the suite rather than in someone's memory.