Assertion Roulette Anti-Pattern
Assertion roulette is a test smell where a test contains many assertions of equal weight, so a failure reports the first to trip without indicating which matters, hiding the real defect behind an.
Definition
Assertion roulette is a testing anti-pattern where a single test function contains multiple unrelated assertions such that when the test fails the reported assertion is whichever happened to be checked first, giving no signal about which behavior broke and forcing the reader to inspect every assertion to find the cause.
Context and scope
Applied in unit and integration test review; linters and test design guides flag high assertion counts per test as a readability and diagnostic smell.
Common misconceptions
- Multiple assertions are fine if they all pass — the problem is diagnostic quality on failure, not the count at green
- Splitting into one-assertion-per-test is always better — related assertions on one behavior belong together; the fix is one assertion per behavior, not per test
Anti-patterns
- Writing a test with ten assertions where the first failure masks the actual regression nine assertions later
- Asserting setup state alongside behavior, so a setup failure looks like a behavior failure
Related concepts
Authoritative source
What it is
Assertion roulette is a testing anti-pattern where a single test function contains multiple unrelated assertions such that when the test fails the reported assertion is whichever happened to be checked first, giving no signal about which behavior broke and forcing the reader to inspect every assertion to find the cause. Applied in unit and integration test review; linters and test design guides flag high assertion counts per test as a readability and diagnostic smell. The distinguishing question is what counts as evidence: a test that passes by accident is worse than no test, because it manufactures false confidence that propagates into release decisions.
How it works
Sound tests exercise a specific behavior contract, isolate the unit under test from environmental noise, and fail with a diagnostic that points at the cause rather than the symptom. Determinism is engineered, not assumed: clocks are fixed, randomness is seeded, and external state is replaced with doubles whose interactions are asserted, not merely stubbed. Coverage measures which behaviors were exercised, not which lines were visited.
When to apply and pitfalls
Apply where the cost of an undetected regression exceeds the cost of writing and maintaining the test. The recurring pitfall is testing the implementation rather than the behavior — such tests break on every refactor and teach nothing. Equally damaging are tests that assert only the happy path, leaving the error branches — where most production bugs live — unexercised.