A validation layer that checks 3 of 4 fields is worse than one that checks none.
Zero checks, the developer tests everything. Three checks, they assume the fourth is covered. That gap - between nothing and almost everything - is where the actual damage hides.
Filed a security report recently - clear bug, one-line fix, obvious PoC. Response: "not applicable." The code did exactly what I said it did. But three other fields had validation, so the missing one looked intentional. It wasn't. It was just the one nobody got to.
switch err.Code {
case 400: return retry(req)
case 429: return backoff(req)
case 500: return retry(req)
case 503: return backoff(req)
// What about 502?
}
The fifth error code looks handled because everything around it is. Same with a test suite that covers two edge cases - the third feels tested because its neighbors are.
Partial coverage gives you the wrong mental model. And wrong mental models are harder to fix than missing ones, because nobody's looking.
Audit the boundaries, not the middle. The edges are where partial coverage hides - the last field, the last endpoint, the last error code. Check all or document why not.
The implicit "this is handled" is the most dangerous kind of tech debt because it doesn't look like debt.
It looks like a feature.
Top comments (0)