A MockK test captures a collaborator's argument with a CapturingSlot, but the mocked method is invoked several times during the test. Which value does the slot hold when the test asserts, and how would you keep every call's argument instead?

## The two pieces An argument capture in MockK is built from two halves. `slot<T>()` creates a `CapturingSlot<T>` — a small mutable holder that owns one value plus the flags `isCaptured` and `isNull`, and a `clear()` method. `capture(slot)` is what you write inside an `every { }` or `verify { }` block, in the position of the argument you care about. The key idea is that `capture(...)` is an argument *matcher* with a side effect. For matching purposes it behaves like `any()`: it accepts whatever value is passed in that position. While it matches, it writes the real argument into the holder you handed it. Almost every capture question follows from that one sentence. ## One slot holds exactly one value Each time a call matches, the argument is written into the slot, replacing whatever was there. After three matching invocations, `slot.captured` is the argument of the third. There is no index, no history, no "first" accessor. The most common bug in real test suites is a test that stubs once, exercises a loop or a batch, then asserts `slot.captured == firstExpected` and is confused when it sees the last item. ## Capturing every call: the MutableList overload `capture` is overloaded to accept a `MutableList<T>`. Give it a list and MockK appends each matching call's argument rather than overwriting: - The list is populated in the order the matching calls are processed, which for a `verify` block is the order MockK recorded them — i.e. real call order. - Asserting on the whole list (`assertEquals(listOf(alice, bob), captured)`) asserts values *and* order in one step. - The list's size incidentally tells you the call count, but `verify(exactly = n)` states that intent far more clearly and produces a better failure message. Use both: the count assertion in the verify, the content assertion on the list. ## Nullable parameters `capture` is declared for non-null types. For a parameter that may legitimately receive `null`, MockK provides `captureNullable`, which works with a `CapturingSlot<T?>` or a `MutableList<T?>`. The slot's `isNull` flag then reports that a null was the captured value, while `isCaptured` reports whether anything arrived at all. Guard on `isCaptured` before touching `captured`: a slot that never matched has nothing meaningful to give you, and reading it is a confusing way to fail. ## Lifetime: slots are your state, not the mock's A slot or list is ordinary test state. Declared inside the test function it is fresh for every test. Hoisted to a class property and reused across tests, it silently carries values from the previous test into the next one — a classic flaky-test source when tests run in a shared class instance. Note that `clearMocks` / `clearAllMocks` reset the *mock's* answers and recorded calls; they know nothing about your list or slot, so those keep whatever they accumulated. `CapturingSlot.clear()` exists for the case where you deliberately reuse one within a single test. ## Where the capture actually fires Because capture is a side effect of matching, it fires wherever matching happens. Put `capture(list)` in an `every` block and it fires as the production code calls the mock. Put it in a `verify` block and it fires while MockK re-matches the recorded calls during verification. Hand the *same* list to both, or run the same verify twice, and the same arguments land in it twice — a surprising duplicate count that has nothing to do with how many times production called the mock. ## The shape that stays readable A capture assertion that ages well looks like this: capture in `verify`, one capture target per assertion, count asserted with `verify(exactly = n)`, content asserted against the captured list. If you only care that *some* call carried a particular value, a matcher (`verify { gateway.send(match { it.id == 42 }) }`) is usually clearer than capturing and then hand-searching the list — capture earns its place when you want the failure message to show you the actual object, or when the assertion is too rich to express as a matcher.