How does MockK's verify(timeout = ...) combine with count modes such as exactly, atLeast and atMost, and why does adding a timeout to a "never happened" assertion (exactly = 0, wasNot Called, or inverse = true) give you false confidence?

## The rule that explains everything MockK's timeout verification is a retry loop around an ordinary verification: while the verification is unsatisfied and the deadline has not passed, re-evaluate; on success, return. Every interaction with count modes falls out of that single rule — ask "is this assertion true right now, before the async work happens?" If yes, the timeout adds nothing at all. ## Lower bounds: where timeout earns its keep `atLeast = n` starts out false when fewer than n calls have been recorded, so the loop keeps retrying and the verification becomes true exactly when the nth call arrives. This is the natural pairing: ``` verify(timeout = 2000, atLeast = 3) { collector.publish(any()) } ``` The default `atLeast = 1` is the same shape, which is why the plain `verify(timeout = ...) { ... }` form behaves so intuitively. ## Upper bounds and exact counts: partial at best `atMost = n` is satisfied whenever the recorded count is at or below n — which it usually is at time zero. The loop exits on the first evaluation and you have proved nothing; the excess calls you were worried about may all still be queued. `exactly = n` is a genuine half-measure. It is false while the count is below n, so the loop does wait for the nth call. But the moment the count hits n the verification succeeds and `verify` returns. A surplus n+1th call that arrives a millisecond later is never seen. So `exactly` with a timeout enforces the lower bound reliably and the upper bound only by luck of timing. If the upper bound matters, you need a different mechanism entirely: wait for a deterministic end-of-work signal, then assert the exact count with a plain, non-timeout verify. ## Negative assertions: the false-confidence trap The worst case is asserting that something never happens: ``` // looks careful, proves nothing verify(timeout = 2000, exactly = 0) { auditLog.record(any()) } verify(timeout = 2000) { auditLog wasNot Called } verify(timeout = 2000, inverse = true) { auditLog.record(any()) } ``` All three are true before the background work has had a chance to do anything, so all three succeed on the first evaluation and return immediately. The test costs nothing, always passes locally, and will pass just as happily on the day the code starts making the forbidden call — because the call arrives after the assertion already returned. The number `2000` is pure decoration; reviewers read it as patience the test does not have. ## The correct shape for asserting absence in async code Absence is only meaningful relative to a point in time you can defend. The reliable pattern is to establish a barrier out of something positive that you *do* expect, and then assert the negative once, without a timeout: ``` // 1. wait for a real completion signal verify(timeout = 2000) { listener.onFinished(any()) } // 2. now the pipeline is done; assert the negative verify(exactly = 0) { auditLog.record(any()) } ``` The barrier does the waiting; the negative assertion is then evaluated at a defensible moment. If there is no observable completion signal to wait for, the honest answer is that the production code lacks a testable seam — inject the executor or dispatcher so the work is deterministic, rather than dressing the race up as a timeout. ## Cost asymmetry to keep in mind Because the loop exits on success, timeouts are free on the paths where they work (lower bounds that eventually hold) and free on the paths where they are useless (already-true negatives). The only case that pays the full deadline is a genuine failure. That asymmetry is why generous timeouts are fine, and also why a suite full of decorative timeouts on negative assertions never shows up as slow — the uselessness is invisible in the run time.