There’s a comforting feeling that comes from a green test suite — the sense that the code is, broadly, okay. That feeling is doing more work than it’s entitled to. A passing test proves exactly one narrow thing: for this specific input, under these specific conditions, the code produced this specific expected output, at the moment the test ran. It says nothing about the input you didn’t try, the condition you didn’t set up, or the way the code will behave next month after three unrelated changes land nearby. The suite passing is real evidence, but it’s evidence about a small, explicit slice of behavior — not a certificate of general health, however much it feels like one.

The gap between those two readings is where a particular kind of incident comes from: full coverage, all green, and a bug in production anyway. This isn’t a contradiction, because the tests were never claiming what the team read into them. They verified the paths someone thought to write down. The bug lived in a path nobody wrote down — an interaction between two features tested separately but never together, an input shape nobody considered, a timing window too narrow to hit in a deterministic test run. The suite was telling the truth the whole time; the team was just asking it a broader question than it could answer, and hearing “yes” to a question it was never asked.

This suggests a different way to read a test suite: not as a health score but as a map of what’s been checked, with the unmapped area being exactly as large as it always was. A high number — ninety percent coverage, a thousand passing tests — describes the size of the checked area, not the absence of problems in the rest of it. Two codebases can have identical coverage numbers and wildly different risk profiles, because one covered the paths that actually matter and the other covered the paths that were easiest to write tests for. The number is a proxy, and like most proxies, it’s informative right up until people start optimizing it directly, at which point it measures effort spent rather than risk removed.

The corrective isn’t to distrust tests — it’s to be precise about what a given test is claiming, and to notice when you’re about to generalize past that claim. A unit test claims something about a function in isolation; it says nothing about how that function behaves wired into the rest of the system, which is a different claim requiring a different test. A test with mocked dependencies claims something about your code’s logic; it says nothing about whether your assumptions about the mocked thing are true, which is why a suite can be green while the real dependency has quietly changed shape underneath it. Each test type answers one question. Treating any of them as answering all the adjacent questions is where the false confidence sneaks in — the tests didn’t lie, the reading of them did.

None of this argues for fewer tests or for cynicism about testing generally — a large, well-aimed suite genuinely reduces risk and genuinely catches real bugs, and that value is not in dispute. It argues for holding the result with the right level of certainty: a passing suite is strong local evidence and weak global evidence, and conflating the two is what turns “all green” into a false sense of safety rather than an honest, bounded one. The discipline is to keep asking, especially after the suite passes, what it didn’t check — because that unchecked area is where the next incident is quietly waiting, unaffected by how good the dashboard looks.