The thread so far has been about the limits of what a passing test tells you — narrow rather than broad, honest about a small claim rather than a certificate of health, verified only if the assertion itself was right. All of that still assumes the test exists. There’s a prior gap that swallows all the others: the test that was never written, for a case nobody thought of, sitting in exactly the blind spot that made it invisible in the first place. Coverage tools can tell you which lines a test touches. Nothing can tell you which scenarios you failed to imagine, because the absence of an imagined scenario leaves no trace to detect.

This is a different failure mode than the earlier ones in the thread, and it’s worth distinguishing because the fix is different too. A wrong assertion is a mistake within a test you did write — you can catch it with review, with a second pair of eyes, with the “would this still pass if I were wrong” question. A missing test is a mistake in the boundary of what you thought to test at all, and no amount of scrutinizing existing tests helps, because the problem isn’t inside them. You’re not looking for a bug in your verification; you’re looking for the edge of your own imagination, which is a much harder thing to inspect because you’re using the same imagination to look.

The scenarios that go missing this way tend to share a shape: they require thinking outside the intended use of the system, and intended use is exactly what’s easiest to think about because it’s what you designed for. The malformed input that isn’t malicious, just unlucky. The two features that individually work but interact badly when used together in an order nobody planned. The state that arises from a partial failure — a write that succeeded but whose acknowledgment got lost — rather than from a clean success or a clean failure. The load pattern that’s realistic for actual users but never occurred to whoever wrote example data. None of these are exotic; they’re just outside the frame the tests were written inside, and that frame is invisible from within it.

A few practices push against this, not by eliminating the blind spot but by triangulating around it with perspectives that don’t share it. Someone other than the implementer proposing test cases, because they’ll bring a different intended-use model and different blind spots that don’t overlap with the author’s. Property-based or generative testing, which doesn’t ask you to imagine specific bad inputs but instead searches a space of them mechanically, catching the malformed-but-unlikely case you’d never have thought to write by hand. Production incidents treated as a primary source of missing test cases — every real failure is proof that some scenario existed outside your imagination, and the cheapest thing you can do with that proof is turn it into a permanent test rather than a one-off fix. Chaos and fault-injection testing, which forces partial-failure states into existence rather than waiting for imagination to conjure them.

This closes the thread’s real argument: a test suite is not a map of your system’s risk, it’s a map of what you thought to check, and those two maps only coincide by luck or by deliberate effort to widen the second toward the first. Passing tests are narrow and true within their claim; correct assertions still only cover imagined scenarios; and the imagined scenarios are always smaller than the possible ones, no matter how careful anyone was. Respecting that gap — rather than reading a green suite as safety — is what turns testing from a checkbox into an actual practice of finding out what you don’t know, which was always the harder and more useful half of the job.