You are setting the house style for a Kotlin service whose handlers orchestrate several collaborators — some orderings are genuinely contractual, most are incidental. How do you decide, per test, between MockK's plain verify, verifyOrder, verifyAll and verifySequence, and how does the scoping of an exhaustive block affect that decision?

## Why this is a policy question, not a preference MockK's four verification modes sit on two independent axes — completeness (are unlisted calls allowed?) and order (must matched calls appear in listed order?). `verify` asserts neither, `verifyOrder` asserts order only, `verifyAll` completeness only, `verifySequence` both. Choosing badly does not produce a wrong test; it produces a test that fails for reasons unrelated to the behaviour it names. Over a suite of thousands, that is what teaches engineers to edit assertions without reading them, which is how interaction tests stop catching anything. ## Axis one: is the order contractual? Order deserves an assertion when the sequence carries a guarantee that no return value expresses: - **Causal/transactional**: `begin` → `save` → `commit`. If save escapes the transaction, nothing about the returned value changes but the system is broken. - **Resource protocols**: open before write before close; acquire before release. - **Externally observable order**: audit written before the response is emitted; idempotency key persisted before the outbound call. Order does *not* deserve an assertion when it is an artefact of how the method happens to be written — two independent reads, a cache lookup relative to a metrics counter, arguments assembled in some sequence. Asserting incidental order buys nothing and breaks on every harmless refactor. ## Axis two: is completeness contractual? Exhaustiveness earns its cost when an *extra* call is a defect in itself: - Outbound ports with cost or side effects: sending an email twice, charging a card, publishing an event. - N+1 protection on a repository port for a hot path. - Protocol drivers where an unexpected frame is a bug. It is a poor default on wide, general-purpose interfaces, on collaborators that also carry telemetry, and anywhere relaxed mocks are in play — a relaxed mock answers calls nobody thought about (accessors, `size`, id getters), and each becomes a record an exhaustive block demands you cover. ## Scoping: the lever most people miss Exhaustiveness in MockK is scoped to the mocks **referenced inside the block**, not to the test. This is what makes strict verification survivable in a multi-collaborator handler: ```kotlin // Strong statement about the outbound port only verifyAll { gateway.charge(order.id, order.total) } // Everything else verified loosely, on purpose verify { repo.save(any()) } verifyOrder { tx.begin(); repo.save(any()); tx.commit() } ``` The `verifyAll` block freezes the interaction with `gateway` and says nothing about `repo`, `tx` or the metrics collaborator. Mixing several mocks into one exhaustive block is the mistake: it silently freezes all of them, and then the first unrelated call anywhere breaks a test whose name mentions payments. ## Design beats DSL When a collaborator is too chatty to verify exhaustively, the honest fix is usually interface segregation: the domain port and the telemetry port become different types, so the telemetry traffic lands on a mock the strict block never names. That preserves the strong guarantee where it matters and removes the churn, without reaching for record-muting helpers. Muting should be a last resort and always carry a comment, because a call excluded from the record is invisible to *every* later assertion, not just the strict one. ## Nondeterminism ends the discussion If the collaborators are invoked from several threads or concurrently launched coroutines, the recorded order is not a contract at all — it is a race outcome. Asserting it produces a flaky suite. There the right answers are to assert the invariant that actually holds (a call happened, a count, a causal pair enforced by the code itself) or to make the production code's ordering explicit and test that instead. ## Cost and diagnosability One more criterion: which mode gives the best failure message for the mistake you are guarding against? A `verifySequence` failure on a wide mock produces a wall of recorded calls and a reader who cannot tell which difference mattered. A focused `verifyOrder` of three calls fails with a message that names the broken causality. Prefer the mode whose failure explains itself. ## The house rule I would write down 1. Default to plain `verify` with explicit counts where the count matters. 2. Add `verifyOrder` only for named causal chains; list the minimum number of calls that expresses the causality. 3. Use `verifyAll` — never `verifySequence` — when completeness is the point but order is not, and scope it to a single narrow port per block. 4. Reserve `verifySequence` for protocol-shaped collaborators, and treat a failure there as a design question, not an assertion to update. 5. Never assert order across concurrently invoked collaborators. 6. If a strict block is noisy, split the interface before you loosen the mode.