An exception test is green, but the exception it observed actually came from test setup rather than from the call being specified. How do you write exception assertions so they cannot pass for the wrong reason?

## How an exception test lies A passing exception test proves only "something of type T escaped this block". Every gap between that statement and the behaviour you meant to specify is a way for the test to be green while the feature is broken. There are four recurring gaps. ### 1. The lambda is too wide ```java assertThrows(IllegalStateException.class, () -> { Account account = repo.load(id); // may throw IllegalStateException account.freeze(); // may throw IllegalStateException account.withdraw(10); // the behaviour under test }); ``` Any of the three lines satisfies the assertion. If `repo.load` starts failing — a fixture change, a missing row, a misconfigured double — the test stays green and the withdrawal rule is no longer covered. The fix is mechanical: arrangement above, one statement inside. ```java Account account = repo.load(id); account.freeze(); assertThrows(IllegalStateException.class, () -> account.withdraw(10)); ``` This also improves the failure report: when it does break, the stack trace points at the call you care about instead of somewhere in a five-line block. ### 2. The expected type is too broad `assertThrows(Exception.class, ...)` passes for anything at all, including a `NullPointerException` caused by an unconfigured collaborator returning null — which means the test passes because the code is broken in a *different* way. `RuntimeException` is barely better. Even a plausibly-specific type can be too wide: `IllegalArgumentException` is satisfied by `NumberFormatException`, so a parsing bug can satisfy a range-validation test. Use the narrowest type that expresses the contract; use `assertThrowsExactly` when a subclass would genuinely be a different failure. ### 3. Nothing about the exception is asserted A method can have many failure paths that share one exception type. If the code under test throws `ValidationException` for a missing field, an out-of-range value and an unknown currency, then asserting only the type means all three paths pass every one of your three tests. Capture the returned exception and assert something discriminating: - a **typed field or error code** — best, because it is machine-checkable and survives copy edits; - a **message fragment** via `contains` or a regex — acceptable when the message embeds the discriminating value; - the **exact message** — only when the message is itself a contract, such as a response payload, because prose changes and localisation break it. ### 4. The wrapping layer is not checked Infrastructure code wraps: a `SQLException` becomes a `DataAccessException`, a reflective call wraps in `InvocationTargetException`, a `Future` wraps in `ExecutionException`, a retry decorator may re-wrap on each attempt. If the contract is "the driver failure is translated but preserved", the test must walk the chain: `assertInstanceOf(SQLException.class, ex.getCause())`, or `assertSame(original, ex.getCause())` when the *same* instance must propagate. Asserting only the wrapper type leaves the translation — the part most likely to regress — untested. ## Mutation as the acceptance criterion The reliable check for all four gaps is: **can this test fail?** Deliberately break the production line the test targets and confirm the test goes red; then restore it. This is manual mutation testing, and it catches the case where a test was written against already-green code and never actually exercised the path. Tools that mutate automatically report the same information at suite scale, and exception paths are exactly where their findings are most valuable, because those paths are the ones developers verify least. A cheaper habit with the same effect: write the test before the fix on a bug ticket, and watch it fail for the right reason — check the failure message names the expected exception rather than reporting some unrelated error. ## Test doubles as a source of false positives When a collaborator is replaced by a test double, two things can go wrong. The double may be configured to throw, so the assertion observes the double's exception and never reaches the logic being specified — legitimate when that *is* the scenario, misleading when it is incidental. Or the double may be under-configured and return null, and the resulting `NullPointerException` satisfies a broad expected type. Both are avoided by the same rules: narrow types, and asserting a discriminating property that only the real code path can produce. ## Reporting and readability Two smaller habits pay off. Give the assertion a message or use the message-supplier overload when the failure would otherwise be cryptic. And when a test makes several claims about one exception, group them so all are reported — otherwise the first mismatch hides the rest, and you iterate one assertion per run. ## The checklist - One statement inside the lambda; arrangement outside. - Narrowest meaningful type; consider exact matching for sibling subtypes. - Assert a discriminating property of the returned exception, preferring structured fields to prose. - Assert the cause chain wherever a layer translates exceptions. - Confirm the test can fail by breaking the code once.