A mocked collaborator is called several times during one test and you need to assert on each argument it received. Explain how Mockito's ArgumentCaptor behaves across multiple invocations and how you would write that verification.

## Behaviour across invocations An `ArgumentCaptor` is not a single-value holder. Internally it keeps a list; each time its `capture()` matcher is evaluated against a matched invocation it appends the argument. So verifying a repeated call with one captor gives you the full sequence: ```java ArgumentCaptor<Email> captor = ArgumentCaptor.forClass(Email.class); verify(mailer, times(3)).send(captor.capture()); List<Email> sent = captor.getAllValues(); // size 3, invocation order Email last = captor.getValue(); // == sent.get(2) ``` `getValue()` is defined as the last captured value. This is the number-one source of weak tests: a service sends three notifications, the test asserts on `getValue()`, and two wrong payloads go unnoticed. If a method can be called more than once, verify with an explicit count and assert on `getAllValues()`. ## Ordering guarantees Values appear in the order the invocations happened on that mock, not in the order you wrote the verifications. For ordering *across different mocks*, `getAllValues()` cannot help - use `InOrder`: ```java InOrder order = inOrder(repo, mailer); order.verify(repo).save(any()); order.verify(mailer).send(any()); ``` A captor answers "what was sent"; `InOrder` answers "in what sequence relative to other collaborators". ## Accumulation and reuse The captor's list is never cleared. Two verifications with the same captor append to the same list: ```java verify(mailer).send(captor.capture()); // 1 value verify(auditMailer).send(captor.capture()); // now 2 values in one list ``` That is occasionally useful but usually a trap; prefer one captor per logical assertion, which `@Captor` fields make cheap. ## The mutable-argument trap Captors store references. Production code that reuses a single mutable object across calls: ```java Email buf = new Email(); for (String to : recipients) { buf.setTo(to); mailer.send(buf); } ``` yields three captured entries that are all the same instance with the final recipient. The test then reports something baffling like "expected [a, b, c] but was [c, c, c]". Remedies, in order of preference: make the payload immutable (usually the right production fix); assert inside a `doAnswer` that copies the relevant fields at call time; or capture a derived value by stubbing with an answer that records `email.to()`. ```java List<String> seen = new ArrayList<>(); doAnswer(inv -> { seen.add(inv.<Email>getArgument(0).to()); return null; }) .when(mailer).send(any()); ``` ## Filtering which calls get captured The captor records only invocations the verification actually matches. Sibling arguments narrow it: ```java verify(client, atLeastOnce()).post(eq("/orders"), captor.capture()); ``` captures bodies only for `/orders` calls. This is a clean way to slice a chatty collaborator - loose on the payload you want to inspect, strict on the routing arguments. Note that `atLeastOnce()` combined with assertions on `getAllValues().size()` re-implements a count check; prefer stating the count in `times(n)` so the failure message comes from Mockito's verification rather than from a size assertion. ## Choosing assertions With AssertJ, `extracting(...).containsExactly(...)` asserts values and order in one line and prints a readable diff. `containsExactlyInAnyOrder` when order is genuinely not part of the contract - do not assert order you do not care about, it makes the test brittle against harmless refactors. ## Interview framing Expected content: one captor collects all matched invocations, `getAllValues()` in invocation order, `getValue()` is just the last and is a trap for multi-call scenarios, verification count belongs in `times(n)`, the list accumulates across verifications, and captured values are references so mutation after the call is visible.