A MockK assertion `verify(exactly = 2) { repo.save(any()) }` fails, reporting a different number of matching calls than you expected. How do you work out whether the production code or the assertion is wrong?

## Read the failure before touching the code MockK's verification failure text carries three pieces of information: the **expected call**, rendered with the matchers you wrote (`any()`, `eq(...)`, `match { }` appear as such); **how many matching calls** it found; and the **calls it actually recorded** on that mock. Most count mismatches are solved by lining the recorded list up against the expected call — the arguments differ, or a method you forgot about shows up, or the list is empty because the mock was never the one the code used. ## The count is over matching calls, not invocations This is the point candidates most often miss. `verify(exactly = 2) { repo.save(any()) }` does not ask "was `save` called twice"; it asks "how many recorded calls match `save` with an argument matched by `any()`". Matcher breadth defines the population you are counting: - `any()` counts every `save`, whatever the argument. Two saves of different users are two matching calls. - `eq(userA)` counts only saves of `userA`. If production saved `userA` once and `userB` once, `exactly = 2` with `eq(userA)` fails at 1 while `any()` passes at 2. So the first diagnostic move after reading the message is to *narrow* the matchers deliberately and see how the count splits. That tells you whether the surplus calls carried different arguments — usually the difference between "the code does more work than I thought" and "the code does the same work twice". ## The rest of the checklist **Overloads and default arguments.** Overloads are distinct methods; a stub or verification on one is blind to the other. Kotlin default arguments can also route through a synthetic overload, so a call site that looks identical to your verification may not be. **Argument equality.** Matching a literal argument uses `equals()`. Data classes give structural equality; a plain class without an `equals()` override degrades to reference equality, so a call with an equal-but-not-identical object is *not* counted. If a count reads lower than the recorded list suggests, suspect this and switch to `match { }` on the fields you care about. **Where the extra calls come from.** Common real sources: a retry or resilience wrapper duplicating a lower-level retry; a listener or subscriber registered in two places; a framework invoking a handler more than once per event; shared `@BeforeEach` setup that exercises the collaborator before the test body runs; a loop that was meant to batch. **Mock state across tests.** Recorded calls accumulate on a mock for as long as that mock lives. A mock created once for the whole class and not reset carries calls from earlier tests, so counts creep upward as the suite grows and the failure looks order-dependent. Recreating the mock per test, or clearing it between tests, removes this whole class of confusion. **Timing.** If the call is made on another thread or from a coroutine that has not completed when `verify` runs, the count reflects whatever had been recorded at that instant. Diagnose it as a timing problem rather than a count problem — the fix belongs to how you wait for the work, not to the number in the assertion. ## Deciding who is wrong Once you know what the extra (or missing) calls are, the judgement is about intent: - The surplus call is **real, correct work** you had not modelled — the assertion was over-specified. Either widen it, or split it into two assertions with narrower matchers so the test states what it means. - The surplus call is a **duplicate effect** — a second charge, a second email, a second publish. The code is wrong and the assertion just earned its place. - The count is **lower** than expected and the recorded list shows the calls happened — matching is the problem: wrong matchers, wrong overload, equality semantics. - The recorded list is **empty** — you are verifying a mock the code never used, which is a wiring problem, not a counting one. ## The habit that prevents most of these Write the narrowest matchers the assertion actually needs. `verify(exactly = 1) { repo.save(match { it.id == order.id }) }` fails with a message about *which* save was expected, whereas `any()` with a count only tells you a number moved. Narrow matchers turn count failures into argument failures, and argument failures are much easier to read.