Beyond asserting an exact call count, what verification modes does Mockito offer for expressing 'not at all', 'at least n times' and 'at most n times', and when would you prefer each?

## The mode is a pluggable count strategy `verify(mock, mode)` hands every recorded invocation matching your description to a `VerificationMode`, which decides pass or fail. Mockito ships several count strategies on the `Mockito`/`org.mockito.Mockito` static API. ## never() `verify(mock, never()).sendEmail(any())` asserts that no matching invocation happened. It is literally implemented as `times(0)`, but the dedicated name produces a dedicated failure type and message ("Never wanted here ... but invoked here") that points at the offending call site, which `times(0)` phrasing would obscure. The scope matters: `never()` is about *one described invocation on one mock*. `verify(mailer, never()).send(eq("[email protected]"), any())` says nothing about `send` with other arguments, and nothing about the other methods on `mailer`. Asserting that a collaborator was left entirely alone is a different, whole-mock assertion. ## atLeastOnce() and atLeast(n) Lower bounds. `verify(metrics, atLeastOnce()).increment("orders")` passes with one call or fifty. Use them where the code legitimately may call more than the minimum and the extra calls are harmless: idempotent metrics, logging, a poll loop whose iteration count depends on timing. The cost is sensitivity: a lower-bound verification cannot catch the bug where a refactor makes the collaborator get hit ten times instead of once. If duplicate calls would be a defect - a payment charge, an outbound email, an expensive query - the lower bound is the wrong tool and `times(n)` is right. ## atMost(n) An upper bound: at most *n* matching calls, and zero passes too. It is the natural way to express "do not do this more than necessary" without pinning the exact number, e.g. "the cache must not load the same key more than once". Because zero passes, `atMost` alone rarely proves the behaviour you want; a common pattern is pairing an exact `times(1)` for the first read with the caching assertion, or simply using `times(1)` for both. One mechanical restriction: `atMost()` and `never()` are not supported inside ordered (`InOrder`) verification, because "at most n, in this position of the sequence" has no well-defined meaning; Mockito raises a usage error if you try. ## Choosing between them The question to ask is: *is the number part of the specification, or an artefact of how it happens to be implemented today?* - Number is the specification: charging a card once, publishing one event per order, opening one transaction. Use `times(n)` - the test should fail if it becomes two. - Number is an artefact: how many times a stream is polled, how often a clock is read, how many log lines are emitted. Use a bound, or do not verify it at all. A suite of `atLeastOnce()` everywhere is a smell in the opposite direction from over-verification: it looks like it checks behaviour but tolerates almost anything, so it neither documents nor protects. ## Failure semantics Each mode produces a different diagnosis. Exact and lower-bound failures where nothing matched report a not-invoked failure; exact and upper-bound failures where too many matched report a too-many-invocations failure with the extra call's stack trace; `never()` violations report a never-wanted failure. Reading which of these you got tells you immediately whether the problem is "my code did not call it", "it called it with different arguments", or "it called it more often than I expected".