Besides checking that calls were verified, MockK can flag stubs that were never used, via checkUnnecessaryStub. What condition makes it throw, what class of bug does it catch that confirmVerified structurally cannot, and when does it produce false alarms?

## Two books, two blind spots MockK maintains, per mock, an **answer table** (what `every { }` registered) and a **call record** (what was actually invoked). Exhaustive verification tools exist for both sides: | Tool | Reads | Complains about | |---|---|---| | `confirmVerified(mock)` | call record | invocations that no `verify` matched | | `checkUnnecessaryStub(mock)` | answer table | stubs that no invocation matched | They are structurally blind to each other's territory. A test can be fully exhaustive on verification and still be full of dead stubs, because stubbing writes nothing to the record — `confirmVerified` has nothing to see. Symmetrically, `checkUnnecessaryStub` says nothing about calls that happened but went unverified. ## The failure condition `checkUnnecessaryStub(vararg mocks)` throws an `AssertionError` when any of the given mocks carries a stub that was never matched by an actual call. "Matched" is the same matcher machinery used everywhere else, which is what makes the check interesting: a stub registered as `every { repo.findById(1) } returns order` is *not* satisfied by a real call to `findById(2)`. ## The bug class it catches Three recurring cases: 1. **Refactor residue.** The code path that used the collaborator moved or disappeared, but the stub stayed. The test still passes and quietly asserts less than its author thought. Dead stubs are dead code with a false sense of coverage attached. 2. **Over-stubbed setup.** Copy-paste test setups grow stubs nobody needs, and readers can no longer tell which stubbing is load-bearing for a given case. 3. **The valuable one: a matcher that does not match.** You stub `findById(1)` and the code actually calls `findById(2)`. On a strict (non-relaxed) mock, the unstubbed call fails loudly anyway. On a **relaxed** mock it does not: the call falls through to the relaxed default — `null`, `0`, an empty collection, a chained child mock — and the test may still go green for entirely the wrong reason. `checkUnnecessaryStub` is the tool that turns that silence into a failure, which is why it pairs naturally with relaxed mocks: relaxation removes the loud failure, this check restores a quieter one. ## False alarms and how to handle them The common false positive is **shared setup**. A `@BeforeEach` (or an `init` block) that stubs everything any test in the class might need guarantees that most tests leave several stubs unused, so the check fires on tests that are perfectly correct. Responses, best first: - Move stubbing into each test, stubbing only what that test exercises. This is the right answer almost always — it also makes each test readable on its own. - Keep in shared setup only the stubs every test genuinely needs. - Apply the check selectively: it takes explicit mocks, so you can check the mocks you care about and leave a deliberately over-stubbed fixture out. A second, subtler case: a stub that exists to *prevent* a call from doing something (defensive stubbing on a mock the test hopes never to touch). That is better expressed as an explicit `verify(exactly = 0) { ... }` or by leaving the mock strict so an unexpected call throws. ## Running it automatically Calling `checkUnnecessaryStub(mock)` by hand at the end of a test is the explicit form. MockK's JUnit 5 extension also exposes it as an opt-in that applies the check after each test, via the `@MockKExtension.CheckUnnecessaryStub` annotation on the test class — the extension mechanics themselves are a separate topic, but it is worth knowing the check does not have to be written out in every test. ## How strict should you be? Dead-stub detection is cheap and its failures are almost always genuine (the exception being shared setup, which is itself a smell), so it scales better across a suite than exhaustive *verification* does. A common house rule: enable stub checking broadly, and reserve `confirmVerified` for the narrow ports where an unexpected call is a real defect. ## Version note This is current MockK (1.13.x) behaviour. `checkUnnecessaryStub` and the extension option are present in recent releases; on much older 1.9/1.10-era versions you should confirm availability against the version on your classpath rather than assume it.