In MockK, if the same interaction is verified twice in one test — say `verify(exactly = 1) { repo.save(user) }` runs inside two different helper functions — does the second verification fail because the call was already 'used up'?

## The model: a recorded-call list, read many times Every MockK mock keeps a list of the calls it actually received. A `verify` block does not mutate that list — it reads it. Given the method and argument matchers you described, MockK counts how many entries match, and compares that number to the bounds you asked for (`exactly`, or `atLeast`/`atMost`). Then it moves on, leaving the list exactly as it found it. That single fact answers the question and several of its cousins: - **Repeated verification is idempotent.** Two identical `verify(exactly = 1)` blocks both see one matching call; both pass. - **Counts never accumulate.** Writing the same `exactly = 1` block twice is not a way to assert two calls. If the code really made two calls, both blocks fail, because each one computes 2 and expects 1. - **Overlapping assertions are legal and independent.** `verify(exactly = 3) { repo.save(any()) }` together with `verify(exactly = 1) { repo.save(adminUser) }` is a coherent description of one run at two granularities. Nothing is subtracted from the broad count by the narrow one. - **Order of verify blocks is irrelevant** to counting. Blocks that assert ordering are a different feature; a plain count block does not care where in the test it sits, only what the recorded list contains at that moment. ## Why this design is convenient Because counts are absolute rather than remaining, verification composes. You can build helper functions — `repo.verifySavedOnce(user)` — and call them from several places, layer a shared "nothing unexpected happened" helper on top of test-specific assertions, and re-verify inside a loop over test data without bookkeeping. No API in MockK requires you to track which recorded calls a previous assertion has already claimed. The cost is that a green suite of count assertions does not, by itself, mean the mock received *only* those calls. Two assertions can both pass while the mock also received a third, entirely unasserted interaction. MockK has a separate exhaustive-verification facility for the "and nothing else" claim; counting alone never makes it. ## The trap this creates A verification helper that hides `verify(exactly = 1) { ... }` reads, at the call site, like "this happened once". Call it twice — in a loop over cases, or from two composed helpers — and a reader may believe the test now expects two calls. It does not; it expects one, twice over. If a helper is genuinely reused per iteration, the count must be parameterised (`verifySaved(times = 2)`) or the assertion moved outside the loop with the right number in it. This is the practical reason to state counts in the helper's name or signature rather than burying a fixed `exactly = 1` inside it. ## What does change the recorded list The list grows only through real invocations by the code under test. Calls written inside `every { }` blocks are recording, not invocation, and never appear in it. It shrinks only when you reset it — by creating the mock fresh for each test, or by clearing recorded calls between tests. If a count assertion is order-dependent across a test class, that reset is what is missing; verification itself never removed anything. ## How to answer crisply "No — MockK verification is non-destructive. Each block recounts matches over the mock's full recorded-call list, so repeated or overlapping verifications are independent, counts do not add up across blocks, and helpers are safe to compose. The corollary is that passing count assertions never imply the mock received nothing else."