A previously green test that uses MockK's verifySequence starts failing after a teammate adds a metrics call to the same collaborator — the assertions themselves were not touched. Explain the mechanism, and how you would restore the test without weakening the guarantee that actually matters.

## What actually broke MockK appends every invocation on a mock to a chronological call record. `verifySequence` queries that record with the harshest criterion available: take the recorded calls belonging to the mocks referenced inside the block, and require them to correspond one-to-one and in order with the entries you listed. Not a subsequence — a complete match. So the block is really two assertions welded together: 1. **Completeness** — no recorded call on those mocks is left over. 2. **Order** — the matched calls appear in exactly the listed positions. Adding `metrics.increment(...)` — or a `log`, or an extra `findById` for a new field — on the same mock violates (1) instantly. Nothing about the ordering the test was written to protect has changed; the test failed because `verifySequence` had silently frozen the *entire* interaction, including the parts nobody meant to specify. This is the core brittleness mechanic of exhaustive verification: it converts every future call on that collaborator into a test change. On a narrow, protocol-shaped port that is a feature. On a general-purpose service interface it is a tax paid on every unrelated feature. ## Diagnosing it quickly Read the `AssertionError` message: MockK prints the verification block you wrote and the calls it actually recorded. When the recorded list contains your listed calls in the right order *plus* one extra, the failure is a completeness failure, not an ordering failure. That distinction points straight at the fix. (If instead your listed calls are missing from the recorded list, the problem is matcher mismatch — different arguments — and no change of verification mode will help.) ## Restoring the test **Option 1 — verifyOrder for the contractual part.** Most tests that reach for `verifySequence` only ever cared about causality: the write happened inside the transaction, the flush came after the sends. `verifyOrder` expresses that as a subsequence query, ignoring anything you did not list. The new metrics call falls into a gap and the test survives. ```kotlin verifyOrder { tx.begin() repo.save(any()) tx.commit() } ``` **Option 2 — verifyAll when the set, not the order, is the contract.** If the point was "this handler touches the repository exactly twice", `verifyAll` keeps the completeness guarantee and drops the order requirement. It still fails on the new metrics call if metrics lives on the same mock, so this only helps when the churn is ordering, not extra calls. **Option 3 — narrow the collaborator.** The deepest fix is usually design, not DSL. A collaborator that carries both domain operations and telemetry is doing two jobs; splitting the interface puts the metrics traffic on a separate mock, which the block never references, so exhaustiveness stops seeing it. This is the option that keeps the strong guarantee *and* stops the churn. **Option 4 — exempt genuinely incidental traffic.** MockK can drop nominated calls from the record so they never count against exhaustive checks. Use it sparingly and with a comment, because a muted call is also invisible to any later assertion about it — you have traded a noisy test for a blind spot. **Option 5 — keep verifySequence deliberately.** Some collaborators really are protocols: a transaction manager, a stream that must be opened before written and closed after, a builder-style API, a hardware or wire protocol where an unexpected extra call is itself a bug. There, the test failing on the new call is the system working as designed, and the right response is to update the block and ask whether the new call belongs there at all. ## The judgement to articulate The question an interviewer is probing is whether you know that `verifySequence` specifies a *complete* interaction rather than an ordering, and whether you can pick a mode from the contract instead of from habit. Two axes decide it: does completeness belong in the contract, and does order belong in the contract? Answer both and the mode follows — `verify` (neither), `verifyOrder` (order only), `verifyAll` (completeness only), `verifySequence` (both). A secondary point worth making: brittleness is not inherently bad. A test that fails when someone adds an unreviewed call to a payment gateway is doing its job. The failure mode to avoid is *undirected* strictness — `verifySequence` applied everywhere by default, so the suite screams on changes nobody considers meaningful, and the team learns to edit assertions without reading them.