How does Mockito's InOrder verify the ordering of interactions, and across one or multiple mocks?
answer
- inOrder(mockA, mockB) then verify in sequence
- cross-mock ordering is the key feature
- relative order, gaps allowed
- calls(n) only in InOrder, consumes consecutive
- order assertions are brittle — use when sequence is the contract
basics
~10 sInOrder lets you assert calls happened in a specific sequence. You create inOrder(mockA, mockB), then call inOrder.verify(...) in the order you expect; Mockito checks the calls occurred in that relative order.
solid answer
~50 sPlain verify ignores ordering — it only checks that calls happened. When the sequence matters, you create an InOrder object with InOrder inOrder = inOrder(mockA, mockB) listing the mocks whose order you care about, then issue inOrder.verify(...) calls in the expected sequence. Mockito asserts those interactions occurred in that relative order, and it works across multiple mocks, which is its main value — e.g. verifying a transaction was opened before a save and committed after. InOrder only checks the calls you actually verify; it does not require them to be adjacent or that nothing else happened in between. Calls you don't verify are simply ignored, so it asserts relative, not absolute, ordering. For repeated calls in ordered mode, use the calls(n) verification mode, which consumes exactly n consecutive matching calls rather than all of them the way times does. InOrder is the right tool whenever correctness depends on sequence: begin/commit, lock/unlock, open/write/close.
go deeper
Knows plain verify ignores order and that InOrder exists to check sequence.
Can set up inOrder(...) and verify calls in sequence for a single mock.
Uses cross-mock ordering, understands relative (gaps allowed) semantics and calls(n) vs times(n), and reserves order assertions for genuine sequence contracts.
Judges when ordering is a real invariant (transactional/resource lifecycles) vs incidental, steering the suite away from brittle order coupling.
## The problem InOrder solves Regular `verify(a).foo()` and `verify(b).bar()` assert *that* `foo` and `bar` were called, but say **nothing about which came first**. For some contracts the order is the whole point: you must `beginTransaction()` *before* `save()`, acquire a lock *before* writing, open a stream *before* closing it. That is what `InOrder` is for. ## How to use it ```java InOrder inOrder = inOrder(txManager, repo); service.transfer(a, b); inOrder.verify(txManager).begin(); inOrder.verify(repo).save(a); inOrder.verify(repo).save(b); inOrder.verify(txManager).commit(); ``` Steps: 1. `inOrder(...)` — pass every mock whose ordering you want to check (one or many). 2. Call `inOrder.verify(mock)...` in the **expected sequence**. 3. Mockito walks the global interaction timeline and checks your verified calls appear in that **relative** order. ## Single vs multiple mocks InOrder's real power is **cross-mock** ordering — proving that a call on mock A happened before a call on mock B. (You *can* use it for a single mock too, to order that mock's own calls.) Plain `times`/`verify` can never express cross-mock sequence. ## Relative, not absolute InOrder checks only the calls you actually `verify`, in the order you verify them. It does **not** require: - that the calls were **adjacent** (other calls may sit between them), or - that **nothing else** happened. So it asserts 'A happened, then later B happened', not 'A immediately then B and nothing else'. If you also want exhaustiveness, combine with `verifyNoMoreInteractions`. ## Repeated calls: calls(n) vs times(n) Within InOrder, repeated identical calls behave differently: - `inOrder.verify(mock, times(2)).foo()` matches and consumes **all** occurrences in order. - `inOrder.verify(mock, calls(2)).foo()` consumes **exactly the next 2** consecutive matching calls, leaving the rest for a later `inOrder.verify`. `calls(n)` is **only** valid in ordered verification. ## Failure messages If the order is wrong, Mockito reports 'Verification in order failure' showing what it wanted and where the actual call sat in the timeline. ## When not to use it Ordering assertions are stronger and more brittle than presence assertions. Only assert order when the order is genuinely part of the contract (resource lifecycle, transactional boundaries). Asserting order on calls whose sequence is irrelevant ossifies the implementation.
- Can InOrder verify ordering across two different mocks?Yes — that is its main strength. Pass both into inOrder(mockA, mockB) and verify in sequence; Mockito checks the cross-mock relative order on the shared interaction timeline.
- What is the difference between calls(2) and times(2) inside InOrder?times(2) matches all two occurrences; calls(2) consumes exactly the next two consecutive matching calls, leaving later ones for subsequent inOrder.verify. calls is valid only in ordered verification.
saying these in an interview costs you the question
- Thinking InOrder requires verified calls to be adjacent or that nothing else happened between them
- Forgetting to pass all relevant mocks into inOrder(...) — only listed mocks are ordered
- Using calls(n) outside InOrder (it is ordered-only) or assuming it behaves like times(n)
- Asserting order where sequence does not actually matter, creating brittle tests