skip to content

What is the difference between verifyOrder and verifySequence in MockK? When would each fail given a stream of recorded calls?

level: middleimportance: must knowfreq 60%

answer

  1. verifyOrder = relative order, extras allowed
  2. verifySequence = exact full list, no extras
  3. sequence fails on any missing/extra/reordered call
  4. both span multiple mocks
  5. sequence is precise but brittle

basics

~20 s

verifyOrder checks that the listed calls happened in that relative order, allowing other calls in between or around them. verifySequence is stricter: the listed calls must be the complete, exact, back-to-back list of all calls on those mocks, with nothing else.

solid answer

~40 s

verifyOrder { a.x(); a.y() } asserts x was called before y; extra unverified calls before, between, or after are tolerated — it only checks relative ordering of the listed expectations. verifySequence { a.x(); a.y() } is exhaustive and exact: the recorded calls on the involved mocks must be precisely x then y with no other calls at all, and in that order. So verifySequence fails if there is any additional call, a missing call, or a wrong order; verifyOrder fails only on wrong relative order or a missing listed call. Both span multiple mocks. Use verifyOrder for the part of the interaction you care about; use verifySequence when you must pin the entire interaction protocol, which is more precise but more brittle.

code

kotlin · 4 lines
kotlin
// actual calls: open, query, log, close
verifyOrder { db.open(); db.query(any()); db.close() }   // passes, log ignored
verifySequence { db.open(); db.query(any()); db.close() } // FAILS: log not listed
verifySequence { db.open(); db.query(any()); db.log(any()); db.close() } // passes

go deeper

for a junior

Knows verifyOrder checks order and verifySequence is stricter.

for a middle

Articulates that sequence is exhaustive (no extras) while order tolerates unlisted calls, and predicts pass/fail cases.

for a senior

Chooses the right verifier per scenario and warns about verifySequence brittleness with relaxed mocks.

for a principal

Guides when locking a full interaction protocol is worth the brittleness vs verifying only the load-bearing happens-before relationships.

## Two ordering verifiers MockK offers two ordered checks beyond the unordered `verify`: ### `verifyOrder` — relative order, non-exhaustive ```kotlin verifyOrder { db.open() db.query(any()) db.close() } ``` This asserts only that, among the recorded calls, `open` came **before** `query`, which came **before** `close`. **Other calls** (logging, metrics, repeated queries) may appear before, between, or after the listed ones — they are ignored. It fails if a listed call is missing or if the relative order is violated. ### `verifySequence` — exact, exhaustive, ordered ```kotlin verifySequence { db.open() db.query(any()) db.close() } ``` This asserts the **complete** list of calls on the involved mocks is **exactly** these three, in this order, with **nothing else**. Any extra call, any missing call, or any reordering fails the test. ## Failure matrix Suppose the actual recorded calls are: `open, query, log, close`. - `verifyOrder { open; query; close }` → **passes** (relative order holds; `log` ignored). - `verifySequence { open; query; close }` → **fails** (the unlisted `log` breaks exhaustiveness). - `verifySequence { open; query; log; close }` → **passes** (lists every call in order). ## Multi-mock scope Both verifiers consider calls **across all mocks referenced** in the block. So you can assert ordering between methods of different mocks (e.g., `cache.get()` before `db.query()`). ## Matchers still apply The lambda bodies use the same argument matchers (`any()`, `eq()`, slots) as `every`/`verify`. Ordering is evaluated over the **matching** invocations. ## Choosing between them - Reach for `verifyOrder` when you care about a **sub-sequence** of the interaction (a happens-before relationship). - Reach for `verifySequence` to lock down the **entire protocol** — powerful for state-machine-like collaborators, but brittle: any new incidental call breaks it. Avoid it on relaxed mocks that may emit extra calls.

  • Can verifyOrder check ordering between two different mocks?
    Yes. Both verifyOrder and verifySequence consider the merged call timeline across every mock referenced in the block.
  • Why might verifySequence be a poor fit for a relaxed mock?
    Relaxed mocks answer any call without setup, so production code may emit incidental extra calls that break the exhaustive sequence.

verifyOrder is 'A boarded before B'; verifySequence is the full passenger manifest in boarding order with no stowaways.

saying these in an interview costs you the question

  • Saying verifyOrder also requires no other calls (that's verifySequence)
  • Thinking verifySequence ignores unlisted calls
  • Believing ordering verifiers only work on a single mock
  • Defaulting to verifySequence everywhere, creating brittle tests

context

resolving links…