Mockito's InOrder handle has its own verifyNoMoreInteractions(), and there is also the static Mockito.verifyNoMoreInteractions(mock). How do the two differ, and when does one pass while the other fails?

## Two different questions Mockito marks invocations as verified as you assert on them. Both no-more-interactions checks look at what is left over, but they scope the search differently. The static Mockito.verifyNoMoreInteractions(mock...) scans the entire invocation list of each mock and fails on the first invocation with no verified mark, printing it as an 'unwanted' interaction. Position is irrelevant. It is the exhaustive claim: every call this mock received was accounted for by this test. inOrder.verifyNoMoreInteractions() uses the handle's ordering context. It asks whether any invocation on the handle's mocks occurred after the last position the cursor reached. Invocations before that point — including ones the test deliberately skipped over — do not matter. It is the positional claim: after the protocol steps I verified, nothing more happened. ## The canonical divergence mock.foo(); mock.bar(); with InOrder inOrder = inOrder(mock); inOrder.verify(mock).bar(); inOrder.verifyNoMoreInteractions() passes: foo() is earlier than the last verified invocation, so it is outside the window this check looks at. Mockito.verifyNoMoreInteractions(mock) fails, reporting foo() as an unwanted interaction because nothing verified it. The same test, the same mock, opposite verdicts — which is the whole point of the question. ## Why the InOrder version is scoped that way Ordered verification is intentionally tolerant of gaps so that adding an unrelated interaction does not break unrelated ordering assertions. An ordered no-more-interactions that failed on earlier gaps would contradict that tolerance and make every InOrder test exhaustive by accident. Scoping it to 'after the cursor' gives you a way to close the tail of a protocol — 'begin, save, commit, and then nothing' — without claiming anything about what happened before or between those steps. ## Interaction with consumption modes Because it is defined in terms of verified invocations and cursor position, it interacts with how each mode consumes. After inOrder.verify(mock, calls(2)).poll(), surplus polls stay unverified, so a trailing surplus poll will fail inOrder.verifyNoMoreInteractions(). After atLeast(2), all matching polls were consumed greedily, so the same trailing poll is silently accepted. Choosing the mode therefore changes what the closing assertion can still catch. ## Practical use and cautions Both assertions are over-specification hazards. The static form turns every new interaction with the mock — an added log, a getter, a metrics call — into a failing test in a place unrelated to the change, which is why many teams restrict it to a few tests that genuinely assert 'no side effects', and prefer verifyNoInteractions(mock) for the simpler 'this collaborator was never touched' claim. The InOrder form is narrower and usually safer, since it only forbids a tail. A note on stubbing: with strict stubs (the default under Mockito's JUnit 5 extension), unused stubbings are already reported, so blanket no-more-interactions assertions add less value than they used to. Also remember that verified-ness is per invocation, so a mock reused across phases of a long test can produce confusing results — a shorter test, or clearing the mock between phases, is usually the better answer than a stronger closing assertion.