In MockK, what does a bare `verify { mailer.send(any()) }` with no count parameter actually assert, and how do you assert that the call happened exactly once?

## The parameter defaults are the whole answer MockK's `verify` is a function with default arguments: ```kotlin verify( ordering = Ordering.UNORDERED, inverse = false, atLeast = 1, atMost = Int.MAX_VALUE, exactly = -1, timeout = 0 ) { ... } ``` `exactly = -1` is the sentinel for "unspecified". So an unadorned `verify { mailer.send(any()) }` asserts *at least one* matching call and nothing more. This is the single most common misreading of MockK verification: people write it meaning "this happened" and read it back later as "this happened once". ## Why the difference matters in practice The bugs a count assertion is supposed to catch are precisely the duplicate-call bugs: - a retry wrapper that also retries at a lower layer, so an email goes out twice; - an event listener registered in both a constructor and an init block; - a loop that was meant to batch but sends per item; - a caching layer that stopped caching, doubling calls to a paid API. Every one of those passes a bare `verify`. `verify(exactly = 1) { ... }` catches all of them. ## Choosing a count deliberately - **`exactly = n`** — the count is part of the contract. Non-idempotent effects (payment, mail, publish, delete) belong here, and so does "we call the expensive downstream once per request". - **bare `verify` / `atLeast = 1`** — you care that the collaborator was reached; how many times is an implementation detail you do not want to pin. Legitimate, but be honest that you chose it. - **`atMost = n`** — you are bounding something, typically retries or fan-out, without pinning the exact number. - **`atLeast` with `atMost`** — an explicit range for genuinely non-deterministic call counts. Setting `exactly` fixes both ends of the range, so combining it with `atLeast`/`atMost` in the same call says nothing useful to a reader even where it is accepted; pick one form. Passing a negative `exactly` (other than the -1 sentinel) is rejected outright. ## What a count is actually counting The number is not "how many times this method ran" — it is **how many recorded calls on that mock match this method with these argument matchers**. `verify(exactly = 1) { repo.save(any()) }` fails if `save` ran twice with different arguments, whereas `verify(exactly = 1) { repo.save(user) }` looks only at calls whose argument equals `user`. Widening or narrowing the matchers changes the population being counted, which is the usual explanation for a count that surprises you. Also worth knowing: calls you made while *stubbing* — inside `every { }` — are recording, not invocation, and do not add to the count. Only real invocations by the code under test do. ## Related knobs in the same call `inverse = true` flips the assertion: `verify(inverse = true) { mailer.send(any()) }` asserts the matching call did **not** happen, which is the same practical statement as `exactly = 0`. `ordering` and `timeout` belong to sequencing and asynchronous verification respectively and are separate concerns from counting; mentioning that they exist on the same function is enough here. ## How to say it in an interview The crisp version is three sentences: MockK's `verify` defaults to `atLeast = 1`, so a bare block means *at least once*; if the count matters, write `exactly = n`, and use `atLeast`/`atMost` for a deliberate range; and remember that the count is over calls matching your argument matchers, not over every invocation of the method. Candidates who assume `verify { }` means exactly once tend to have a suite full of assertions that are weaker than they believe.