Order-sensitive mock verification makes a test fail when someone reorders two calls even though observable behaviour is unchanged. How do you decide which orderings are worth asserting across a large test suite?

## Ordering assertions are coupling with a purpose Any interaction test couples a test to how a unit collaborates, not just to what it produces. Ordering assertions raise that coupling: they pin not only which calls happen but their relative positions. That is worth paying for when order carries risk, and pure cost when it does not. ## The decision rule Ask: if these two calls were swapped, what would break for a user or an operator? Real answers include data loss (notify before commit means a consumer can read a record that is not durable), corruption or races (mutate before acquiring the lock), protocol violation (a wire format that requires header before body, or a handshake before payload), resource errors (close before flush), and audit or compliance requirements (log the decision before acting on it). Each of those is a bug you can name, so the ordering is contract and an ordered test is justified. If the honest answer is 'nothing — both orders are correct', the assertion is a snapshot of today's implementation. It will fail during a harmless refactor, cost someone an investigation, and teach the team that interaction tests are noise. ## Prefer the outermost boundary Order assertions are most durable when they describe externally visible sequences: the order of published messages, of HTTP requests to a downstream service, of database statements at a transaction boundary. Ordering internal helper calls freezes structure and blocks refactoring. Where the sequence is truly a protocol, a contract or approval-style test over the emitted sequence can be clearer than a chain of ordered verifications, because it reads as the protocol rather than as test plumbing. ## Keep the assertion minimal Because ordered verification is a subsequence check, you can assert only the pairs that matter and let everything else fall into the gaps. Verify begin before save before commit; do not transcribe every call in between. Reserve closing assertions such as an ordered no-more-interactions for cases where a trailing call would itself be a defect. Minimal ordered assertions survive refactoring; exhaustive ones do not. ## When ordering is pervasive, change the design A codebase where many tests need ordered verification is usually one where sequencing is implicit in procedural code. Making the sequence explicit — a template method or transaction template that owns begin/commit/rollback, a small state machine with legal transitions, a pipeline of steps expressed as data — moves the guarantee into production code where it is enforced for every caller, not only where a test happens to check. Then the unit test for the sequencing object is small and direct, and the collaborators' tests stop needing ordered mocks. That is the highest-leverage move: replace many fragile ordering assertions with one construct that cannot express the wrong order. ## Concurrency caveat Ordering assertions describe the sequence recorded on the mock. Under concurrency that sequence may be nondeterministic even when the code is correct, so an ordered test can become a flaky test that looks like a logic failure. If two calls are genuinely unordered by design, do not assert order; if a happens-before relation is required, prefer asserting it through a mechanism that enforces it rather than through observed call order. ## Team-level guidance I encode this as review guidance rather than a hard rule: an ordered verification should be accompanied by a test name or comment stating the defect it prevents. That single requirement filters out most gratuitous ordering assertions, keeps the remaining ones self-documenting, and gives future maintainers permission to delete the ones that cannot justify themselves.