What does MockK's `verify { repo wasNot Called }` assert, and how is that different from `verify(exactly = 0) { repo.save(any()) }`?

## Two different negatives MockK gives you three ways to assert something did not happen, and they are not interchangeable. **Whole-mock:** `verify { repo wasNot Called }`. `Called` is a MockK object and `wasNot` an infix function; the assertion holds only if the mock has *no recorded calls at all*. It is the strongest negative available and the right one when the point of the test is that a dependency is untouched — no email service on the validation-failure path, no repository when the cache hits, no payment gateway for a rejected order. A list form covers several mocks in one statement: `verify { listOf(mailer, gateway) wasNot Called }`. **Per-call:** `verify(exactly = 0) { repo.save(any()) }`. Only calls matching `save` with those argument matchers are counted, and the count must be zero. Everything else the mock received is irrelevant. This is what you want when the collaborator is legitimately used but one particular interaction must not occur. **Per-call, inverted:** `verify(inverse = true) { repo.save(any()) }` asserts the described call did not happen — practically equivalent to `exactly = 0` for that call, and a matter of team style which one you standardise on. ## Matchers still shape the per-call form `exactly = 0` is only as broad as its matchers. `verify(exactly = 0) { repo.save(premiumUser) }` says nothing about `repo.save(otherUser)`; it asserts that no *matching* call happened. If you mean "never saved anything", write `any()`. If you mean "never saved this particular user", write the specific argument. A negative assertion with narrow matchers passing is very weak evidence, and it is easy to write one by accident. Overloads matter too: `save(user)` and `save(user, options)` are different methods, so `exactly = 0` on one says nothing about the other. `wasNot Called` has no such gap, which is part of why it is the better tool when your claim really is "untouched". ## What counts as a recorded call Only real invocations by the code under test are recorded. Calls you write inside `every { }` while arranging stubs are executed under MockK's recorder to *describe* a call, not to make one, so they leave no recorded call and never break a `wasNot Called` assertion. That surprises people who assume elaborate arrangement disqualifies the strong negative — it does not. What does break it is a genuine invocation from shared setup: a `@BeforeEach` that primes state by calling the collaborator, or a fixture that exercises the object under test before the test body runs. If your `wasNot Called` fails and the test body plainly does not touch the mock, look at setup — and at whether the mock is shared across tests without its recorded calls being reset between them. ## Choosing well A good rule: reach for `wasNot Called` when the *absence of the dependency* is the behaviour under test, and for `exactly = 0` when the dependency is used but one interaction is forbidden. State the reason in the test name — `doesNotChargeGatewayWhenOrderRejected` reads better than a bare assertion and tells the next reader which negative was intended. And note the asymmetry in failure quality: `wasNot Called` failures tell you *something* was called and show what; `exactly = 0` failures point at one signature. Where you can honestly use the whole-mock form, it both asserts more and diagnoses better.