What does Mockito's verifyNoMoreInteractions do, how does it differ from asserting a mock was never used at all, and what failure does it produce?

## Relative versus absolute Mockito has two whole-mock assertions and they differ in what they take into account. - The absolute one asserts the mock recorded **no invocations at all**, independent of anything else the test did. - `verifyNoMoreInteractions(mock)` asserts that **no invocation remains unverified**. Each successful `verify` marks the invocations it matched as verified; this call then fails if any unmarked invocation is left. So the same test can pass `verifyNoMoreInteractions` with ten recorded calls, provided ten matching `verify` assertions preceded it. And with no preceding verifications, the two assertions coincide. ```java verify(repo).save(order); verify(repo).flush(); verifyNoMoreInteractions(repo); // fails if the code called anything else on repo ``` It accepts varargs, so several collaborators can be closed off at once. ## What it buys you Exhaustiveness. Positive verifications alone are open-ended: they prove certain calls happened but tolerate any number of additional ones. Closing the set converts the test into a full statement of the collaborator's protocol for that scenario, which catches genuinely interesting regressions - a duplicated publish, an accidental second save inside a loop, a stray audit write added on a path where it must not happen. That is real value in a narrow set of places: a small port whose protocol is the point of the test, an outbound-effect boundary where surprises are defects, or a regression test written specifically to pin down "and nothing else happened". ## What it costs Every future call on that collaborator, however harmless, fails the test - and it fails at the exhaustive-check line, far from the change that caused it, with a message about an unverified invocation rather than about broken behaviour. Sprinkled through a suite, it produces a maintenance tax that is paid by people who did not write the tests. Stubbing traffic makes this worse. If the code under test calls a method you stubbed to make the scenario run, that call is recorded like any other and is unverified unless you also wrote a `verify` for it. Tests then acquire verifications whose only purpose is to appease the exhaustive check, which is noise. Mockito provides a way to exclude stubbed invocations from the check for exactly this reason. ## Reading the failure A violation raises a no-interactions-wanted error that names the unverified invocation, prints its stack trace, and shows the mock involved. The right first move is to look at that call and ask a design question rather than a mechanical one: *should this call exist?* If yes, either add a real verification for it or drop the exhaustive check; if no, you have found the bug the assertion was written to catch. ## Interaction with strictness Modern Mockito runs strict stubs by default under the JUnit 5 extension. Strict stubs already report unused stubbings and argument mismatches at the end of the test, which removes one of the historical motivations for exhaustive verification ("catch calls I did not expect"). It does not report *extra unstubbed calls* on a mock, so the two mechanisms are complementary - but the residual gap is smaller than people assume, which is another argument for using exhaustive checks deliberately rather than habitually. ## Practical rule Use a positive `verify` for the effects that matter, a targeted negative assertion for the effect that must not happen, and reserve `verifyNoMoreInteractions` for the few tests whose actual subject is the completeness of an interaction protocol.