A Test That Agrees With Itself Isn't A Test

A test that recomputes the same logic the code uses, then compares the two, will never fail. It doesn't matter how badly that logic breaks later — the test and the code will always agree, because they are the same sentence written twice. I watched this happen in a code review recently: a new unit test asserted a value against an inline re-derivation of the very rule it was supposed to be protecting. It was green the day it was written and it would stay green forever, and it protected nothing at all.

This is a more common failure than the phrase "tautological test" makes it sound, and it is dangerous precisely because it is invisible from the outside. The pull request adds test files. The coverage percentage goes up. The pipeline passes. Every signal a busy reviewer or a nervous manager glances at says "this is now safer than it was." None of those signals distinguish a test that exercises the real function from a test that quietly restates the author's assumptions back to themselves and calls it verification.

What made this particular case worth writing about wasn't the tautology itself — that's a known smell, and most experienced engineers will name it once they see it. It was what the tautology was hiding. The reviewer who caught it didn't stop at "this test can't fail." They kept tracing the logic and found that the rule it was meant to protect already existed twice elsewhere in the codebase, written by different hands at different times, in two slightly different dialects. The two versions agreed on the common cases and quietly disagreed on the edges. Nobody had noticed, because nothing had ever forced the disagreement into the open. The new test, rather than catching that drift, had unwittingly copied one of the two versions and declared it correct. It would have kept declaring it correct no matter which of the two kept changing.

That's the part I think is genuinely instructive: a test that can't fail doesn't just fail to add safety, it can actively launder an existing problem into something that looks resolved. Before the test existed, at least the duplication was visible to anyone who went looking. After it existed, the duplication had a green checkmark next to it. That's a worse state, not a neutral one.

The fix the author landed on was structural rather than cosmetic, and it's the reason this is a better story than a simple "watch out for tautologies" cautionary tale. Instead of patching the new test to call something more meaningful, they pulled the duplicated rule out into a single named function, pointed both original call sites at it, and had the test exercise that same function directly. One rule, one place it lives, one test that would actually turn red if someone changed its behaviour without meaning to. The tautology and the duplication turned out to be the same underlying problem wearing two costumes, and fixing the root cause closed off both at once.

I've spent enough years moving between greenfield builds and difficult brownfield systems to know how ordinary this pattern is once you know to look for it. Logic gets written once, then a second caller needs almost the same behaviour, and under deadline pressure it's faster to retype the idea than to go find and generalise the original. Nobody intends for the two copies to diverge. They just do, gradually, as each gets touched independently by people who don't know the other exists. In systems that handle anything sensitive — health records, payment data, anything a customer only handed over because they trusted you to look after it — that kind of silent behavioural drift is exactly the shape of bug that doesn't announce itself with a crash. It just quietly does the wrong thing for a subset of cases, indefinitely, until someone goes looking for an unrelated reason.

The practical habit I'd draw out of this is a single question, and it's one I now ask myself before I trust any new test: could this test ever fail? Not "does it pass" — of course it passes, you just wrote it — but if I changed the behaviour underneath it in a way that mattered, would it turn red? If you can't describe a plausible code change that would break the test, you haven't written a test. You've written documentation of what the code currently does, formatted to look like a safety net. And a test should call the same function the production code calls, not reimplement its reasoning next to it — if writing a test tempts you to re-derive the logic instead of invoking it, that's usually a sign the logic was never properly centralised in the first place.

There's a broader lesson underneath the technical one, and it's about where scrutiny is worth spending. A green pipeline is a claim, not a fact, and claims are worth exactly as much as the thing that produced them. The value in that code review wasn't that someone found a bug — it's that someone refused to accept "the tests pass" as the end of the conversation and kept asking what, specifically, had been checked. That's a cheap habit to adopt and an expensive one to skip. Confidence that hasn't been earned by an actual test of the actual logic is just an unusually well-dressed guess.