When verifying a collaborator's calls, what do count, argument and order assertions each prove?

A verification is not one thing. It is a set of dimensions you may choose to constrain, and each one you add narrows what a passing test permits and widens what a passing test forbids. Choosing well is most of the skill. ## 1. Occurrence and cardinality The weakest form is *it happened at least once*. Stronger forms are *exactly n times*, *at most n times*, and *never*. Cardinality is not decoration - it is often the requirement itself: - **Exactly once** encodes idempotence at the seam. In a video-transcoding queue, a finished upload must produce one job, not two; an at-least-once verification passes on a duplicate enqueue, which is the exact defect worth catching. - **At most n** encodes a retry budget. If the policy is three attempts, a test that only asserts "at least once" says nothing about a runaway loop that calls the downstream service nine times. - **Never** encodes a prohibition. It is the strongest safety statement you can make about a code path, and the easiest to get a false pass from: if the method name or argument you are matching can never match anything, the assertion passes for the wrong reason. Always pair a never-called assertion with a positive test that drives the same call, so you know the check is capable of failing. ## 2. Arguments Three levels of precision, in ascending order of what they prove: - **A catch-all matcher** (any value) proves only that the call shape was used. It is honest when the argument genuinely does not matter, and dishonest when it is used to make a test go green - the verification then reads as if arguments were checked when nothing was checked at all. - **Exact matching** compares the argument against an expected value. This depends on the argument type having meaningful value equality; where equality is identity-based, an exact match silently becomes an identity check and fails for an equivalent object. - **Capture and assert** records the argument that was actually passed and lets you assert on it with ordinary assertions. This is the right tool for a large constructed argument where only two fields carry meaning - assert those two, ignore the rest, and get a failure message that names the field that was wrong instead of dumping two objects side by side. The general rule: constrain the parts of the argument the requirement talks about, and leave the rest free. A verification that pins every field of a job descriptor breaks the first time an unrelated field is added. ## 3. Order By default, verifications are unordered: each says a call happened, none says when. Ordering can be added as *relative order* (this call preceded that one, other calls allowed in between) or as *strict consecutive order* (nothing else in between), and it can span more than one collaborator. Order assertions are the most brittle thing in this toolbox, because most call sequences are incidental - the method happens to do A before B, and doing B before A would be equally correct. Assert order only when **the ordering is itself the requirement**. Real examples: a resource must be opened before it is written; a transaction must begin before work is done; and, in the dispatcher above, the caller's credential scope must be narrowed *before* the job is handed to the worker. Swapping those two lines is a permission escalation - a job briefly queued with elevated rights - and no state assertion anywhere would notice, because the end state is identical either way. That is a sequencing rule worth pinning. ## 4. Exhaustiveness Some libraries offer a check meaning *and no other calls were made on this collaborator*. This converts the verification list into a whitelist: any new outgoing call fails the test even if it is harmless. At a safety-critical seam - the credential collaborator above, an audit sink, a payment client - that is exactly what you want. Applied by default across a suite of a few thousand tests, it is expensive: every ordinary addition breaks a scattering of unrelated tests, and a team of eleven spends its review time relaxing assertions rather than reading them. ## Choosing the level Work backwards from the requirement sentence and constrain only what the sentence constrains. - "Every finished upload enqueues one job for that asset" -> exactly once, with the asset identifier matched exactly, arguments beyond it left free, no order assertion. - "Retries stop after the third attempt" -> at most three, arguments free. - "Credentials are narrowed before dispatch" -> two calls plus a relative-order assertion. - "A viewer-role upload never reaches the privileged path" -> a never-called assertion, plus a sibling test proving the privileged path is reachable at all. Over-specification is the common failure. Each unnecessary dimension is a future false alarm; each missing one is a defect the suite cannot see. Interviewers are checking that you reason about this per requirement rather than reaching for the tightest assertion available.