When You Can't Unit-Test, Make Two Signals Agree

Not every system lets you write a clean unit test. Some runtimes have no static checker, no test framework worth the name, and no way to exercise a function in isolation — your only feedback is “boot the whole thing, send it a real input, and see what happens.” In that world, the question becomes: how do you trust a pass? The answer that’s held up for me is to never trust a single signal. Require two independent confirmations that agree, because in a system without proper tests, either signal alone has a way of lying to you.

The trap of the single happy signal

When the only thing you can observe is the system’s externally visible response, it’s tempting to call that response your test. Input goes in, the expected output comes out, ship it. But a single output can be right for the wrong reasons. The system might return the success response while skipping the work you cared about, or hit a default path that happens to produce the same answer, or short-circuit on something unrelated. One signal tells you an answer came back. It doesn’t tell you the answer came back the way you think it did.

A green result from one signal proves something responded. It doesn’t prove the thing you wanted actually happened.

Two independent signals, agreeing

The discipline that fixes this: define success as two independent observations that have to agree. In the system I’m thinking of — a policy runtime with no local compiler — I judged a test passed only when both the protocol response was the expected accept and the internal log trace showed execution reaching the specific code path I intended. Either alone was insufficient: the right response could come from the wrong path, and the right path could appear in the trace while the final response was still wrong. Demanding both, and that they corroborate each other, is what made a “pass” trustworthy.

The key word is independent. Two signals that come from the same place fail together and lie together. The response and the execution trace are different windows onto the run — one is what the system told the outside world, the other is what it did internally — so when they agree, the agreement means something.

Why agreement beats either signal alone

Think of it as triangulation. Any single measurement has a failure mode where it reads correct while reality isn’t. Two measurements from different angles have to both hit their independent failure modes in a mutually consistent way to fool you — which is far less likely than either one misfiring on its own. You’re not just doubling the checking; you’re requiring two different kinds of “wrong” to conspire. That’s a much higher bar for a false pass to clear.

It also localizes failure. When the two signals disagree — response says accept, trace shows the wrong path — that mismatch is itself diagnostic. It tells you the result is right by accident, which is exactly the bug you’d never catch from the response alone.

Where this shows up beyond exotic runtimes

You don’t need a weird policy language to use this. Anywhere proper isolation testing is hard, two-signal agreement is the move:

• An API call that should also write to a store — assert the response and read the store back. The 200 alone can hide a no-op.
• A deploy that should change behavior — check the deploy reported success and probe the actual changed behavior. “It ran” isn’t “it worked.”
• A migration that should move data — confirm the job finished and count rows on both sides. Completion isn’t correctness.

In each case, one signal is the convenient one everybody checks, and the second is the one that catches the convenient one lying.

Build the second signal in deliberately

The habit is to ask, for anything I can’t cleanly unit-test: what’s my second, independent signal, and does it corroborate the first? If I only have one, I go find another — a log line, a state read, a side-effect probe — before I believe a pass. It’s the same root idea as insisting that a job running isn’t a job working, and it pairs naturally with building a local test harness so the signals are cheap to gather. A single green light in an untestable system is a hope; two independent ones that agree is closer to a fact. If you’ve got a clever second signal you reach for when real tests aren’t an option, I’d love to hear it.