The Check That Cannot Fail and 9 Rules for Real Verification

Have you ever looked at a dashboard full of passing tests and felt a sudden wave of suspicion? You probably should.

There is a very specific danger in software engineering that comes disguised as a green checkmark. It is the check that cannot fail. A safety gate that has never been triggered looks exactly like one that is completely broken. We add rules to block bad code, monitors to page us before disaster strikes, and tests to catch regressions. Over time, these checks sit in our stack and pass quietly.

But that trust is a trap. Once a gate proves itself on day one, nobody reverifies it. A quiet check collapses two different realities into one signal. Either the system is working perfectly, or the alarm is unplugged. When a check is structurally incapable of failing, it stops being an instrument and becomes a decoration. It sells you confidence you have not earned.

To stop building decorations and start building actual safety nets, here are nine rules to live by.

1. Break it on purpose#

A test that has never failed is unproven. Before you trust a green light, you need to manufacture the exact bad scenario the gate exists to catch. If you cannot make the test turn red, it is completely useless.

2. Check at the layer of consequence#

Looking where the light is brightest will not help you. If your website links are broken on the rendered page, checking the source code repository to see if the links exist there will not catch the bug. Point your instruments where the failure actually impacts the user.

3. Silence does not equal health#

A monitor with a firing count of zero for six months is not a metric to celebrate. It is a mystery to solve. Find out when your gate last caught a genuine error. If the answer is never, you have homework to do.

4. Beware the vacuous pass#

This is a classic failure mode. A script searches for errors, looks in an empty directory, and happily reports a pass. Finding nothing is only a valid result if your detector actually looked at real data.

5. Speak the right dialect#

If your checker looks for a specific string but your framework emits a slightly different format, it finds nothing. The test passes while the bug lives on. Disagreement between the checker and the system often comes out as silence, and silence reads as health.

6. Reliability is not validity#

A metric can be perfectly stable while measuring the wrong thing entirely. You need to prove that your test evaluates what it claims to evaluate. Find a transformation your measure should ignore, apply it, and see if the result stays the same.

7. Test the live enforcement point#

Do not run your test against a mock environment or a local copy of your code. Run the bad case against the gate that actually executes in production.

8. Watch out for shared blind spots#

Sometimes a system moves. A schema changes or a directory gets renamed. The gate goes stale, but the test for the gate stays green because it relies on the exact same outdated assumption. A passing test for a dead gate is just a certified blind spot.

9. Delete or demote inert checks#

If a row on your status board cannot be made to fail, delete it entirely. If you must keep it, mark it as informational without the reassuring green checkmark. A check that cannot fail borrows and drains credibility from the checks that actually do the work.

The Takeaway#

We write tests because we want to trust our systems. The next time you see a sea of green across your deployment pipeline, pick one check at random and ask yourself what it would actually take to make it fail. If you do not know the answer, you do not have a test.

** Edited by Generative AI for better readability.