Inside an ordered Mockito verification, what does the calls(2) mode do that neither times(2) nor atLeast(2) does, and when would you reach for it?

## The problem calls(n) solves Ordered verification is cursor-based: each verification consumes some invocations and moves the cursor. That makes the consumption policy of each mode observable, which is where the three modes differ. times(n) in an ordered context asserts that the matching run starting at the cursor has exactly n elements; a further matching call in that run makes it fail. That is what you want when the count is part of the contract, but it makes the test brittle if the number of repetitions is incidental. atLeast(n) passes with n or more, but it is greedy: it marks all the matching invocations it finds as verified and pushes the cursor past them. The count assertion is loose, yet the side effect on the cursor is total — you cannot then verify a later occurrence of the same call separately, and those invocations no longer count as unverified for an ordered no-more-interactions check. calls(n) is the non-greedy middle: exactly n consecutive matching invocations are consumed from the cursor, no upper bound is asserted, and anything beyond them stays unverified and reachable. Mockito's own documentation states it will not fail if the method was called three times (unlike times(2)) and will not mark the third invocation as verified (unlike atLeast(2)). ## Ordered-only by design calls(n) is meaningless without a cursor — 'the next n calls' has no referent in unordered verification — so Mockito rejects it outside an InOrder handle. This is one of several mode restrictions in ordered verification: modes that do not implement the in-order contract, such as atMost, are refused with an error saying that mode is not implemented to work with InOrder. Knowing which modes are legal where is a common senior-level detail. ## A worked shape A batching client polls a queue an unspecified number of times, then flushes, then closes. The contract worth asserting is 'at least two polls happened before the flush, and close came after the flush', not the exact poll count, which depends on batch size and timing. InOrder inOrder = inOrder(client); inOrder.verify(client, calls(2)).poll(); inOrder.verify(client).flush(); inOrder.verify(client).close(); With times(2) this fails whenever the client polls a third time before flushing. With atLeast(2) it passes, but the greedy consumption swallows every poll, including any that occur after the flush — so a stray post-flush poll would go unnoticed by a subsequent ordered check. ## Interaction with verifyNoMoreInteractions Because calls(n) leaves surplus invocations unverified, following it with inOrder.verifyNoMoreInteractions() will fail if any of those surplus calls occurred after the last verified one. That combination is a precise way to say 'exactly this protocol shape, with these repeated steps, and nothing trailing'. With atLeast(n) the same combination is silently weaker, since the extra calls were already marked verified. ## When not to use it If the repetition count is genuinely part of the contract, assert it with times(n) and let a third call fail the test. If neither the count nor the position matters, do not use an ordered mode at all — a plain atLeast(1) is clearer. calls(n) earns its place only when you need to step over a variable-length run and continue verifying the sequence after it, which is a narrow but real situation in protocol-style tests.