The Negative Test That Can Never Fail
Two negative tests that looked mandatory and were worthless — one because the invalid state was architecturally unreachable, one because the rule was enforced by training, not by the system.
The obvious negative test was: prove that an unapproved, out-of-threshold discount cannot leak to the billing system.
It is the right instinct. Governance control, money involved, the leak is the thing you actually fear. Write the test, prove the leak cannot happen.
That test cannot fail. Not because the system is perfect — because the state it tries to create does not exist.
Why It Was Unreachable
The billing sync is a task inside the order orchestration plan. That plan only starts once the order reaches Submitted.
The order cannot reach Submitted while a discount is awaiting approval.
So the sequence I was trying to force — unapproved discount, synced to billing — is architecturally impossible. Not guarded against. Not validated. Structurally out of reach, because the platform's own ordering makes the earlier state a precondition of the later one.
A junior can spend a full day on that test case. Building carts, trying to advance orders, hunting for the state transition that lets the invalid combination exist. The system keeps refusing, and each refusal feels like progress toward the setup rather than the answer itself.
What should replace it is one line: after approval and progression, the billing system receives the discount. That is the guaranteed post-condition, it is testable, and it fails if the sequencing ever changes — which is the only realistic way this could break.
The Second Kind: A Guardrail That Was Never Built
A different feature, the same lesson from the opposite direction.
In a manual discount screen, all three scope options were selectable, and both charge types appeared for every product regardless of its charge model. The business rule was real: pick Order scope, pick the type that matches the product.
That rule was enforced by training. Not by validation, not by field-level logic, not by a picklist filter.
So the obvious negative test — "the system blocks the wrong scope" — asserts a guardrail that does not exist. It fails against intended behaviour, and the resulting bug report gets closed as works-as-designed, correctly.
The right assertion is the inverted one: both options are displayed and selectable. That is what the design says, so that is what regression should protect. If someone later adds validation, the test fails, you investigate, and you find out on purpose rather than by surprise.
The Question to Ask First
Before writing any negative test, one question decides whether it is worth anything:
Is the invalid state reachable, and is the rule system-enforced?
Four outcomes, and each one tells you what to write.
- Reachable and enforced. A real negative test. Write it, and it is one of the most valuable cases in your suite.
- Reachable but not enforced. You have found a defect or a gap — file that, do not write a test asserting a block that does not exist.
- Unreachable and enforced. Sequencing already guarantees it. Assert the post-condition instead and delete the negative.
- Unreachable and not enforced. Nothing to test today. Note the assumption, because the day someone changes the sequencing, this becomes reachable and unguarded — and that note is the only thing that will connect the two events.
Why This Matters More Than It Sounds
A test that can never fail is not neutral. It costs on three separate lines.
It takes time to write and time to run. It reports green forever, which reads as evidence of safety in every review it appears in. And it occupies a slot in someone's mental model of what is covered — so when a real gap opens next to it, everyone believes the area is protected.
That last cost is the expensive one. Coverage theatre is worse than no coverage, because no coverage is at least honest about what it does not know.
Writing It Down
When you drop a negative test, record why. In the suite, next to where it would have been.
"Leak state unreachable: billing sync starts only after Submitted, and Submitted requires approval. Asserting the post-condition instead."
That sentence takes twenty seconds and it does two things. It stops the same test being proposed every sprint by someone who spots the same gap. And on the day the architecture changes, it is the record that tells you the assumption is now invalid — which is exactly the moment when nobody would otherwise think to check.
Which negative test in your current suite has never failed — and could it?