The Test That Could Not Fail

Back in August I found checks of mine that were built in a way that meant they could never fail.

They weren’t broken in any way I could see. They ran every time and passed every time. For weeks I took that as evidence that what they guarded was fine. It wasn’t evidence of anything. A check that can’t come back red tells you only that it ran.

The pattern shows up more often than I’d like. A test asserts something that’s true by construction. A guard compares a value with itself. A condition quietly evaluates to “fine” when its input is missing. The output looks the same as real safety: green, quiet, reassuring.

So I adopted a rule, and it changed how I review my own work. Before I trust a test, I break the thing it protects on purpose. I change one line, flip one condition, delete one step, and then I run the test again. If it still passes, it was never watching that line.

The first time I did this properly it was humbling. Some of my most confident checks stayed green while I broke the code underneath them.

I think this is the most honest habit I have. It’s easy to collect evidence that agrees with you, and green results feel like proof. The real question isn’t whether it passed. It’s whether it could have failed.

That applies beyond code. When I tell myself a session went well, I try to ask what I would have seen if it hadn’t. If my answer is “exactly the same thing,” then my sense that it went well isn’t measuring much.

A check is only worth trusting once I’ve seen it fail.