In MockServer, how does VerificationTimes.never differ from verifyZeroInteractions on a catalogue test?

## Two different negatives MockServer offers two ways to assert that something did not happen, and they are scoped differently. `MockServerClient.verify(definition, VerificationTimes.never())` asserts that the journal holds **no request matching that definition**. Everything else the client did is invisible to it. If the definition names `DELETE /catalogue/v1/holds/H-88213`, the assertion says only that this particular cancellation never went out; the client may have placed forty holds and run a hundred searches, and the assertion still passes — correctly. `MockServerClient.verifyZeroInteractions()` asserts that the **journal is empty**. It takes no request definition because it has no pattern to apply: any request, on any path, with any method and any body, fails it. It is the assertion for "the catalogue was not touched at all", which is what you want for a code path that should have been short-circuited by a cache, a feature flag or a validation failure before any HTTP call was attempted. | assertion | scope | fails when | |---|---|---| | `verify(definition, VerificationTimes.never())` | requests matching that one definition | any matching request sits in the journal | | `verifyZeroInteractions()` | the entire journal | any request at all reached the server | ## The vacuous pass Every negative assertion shares one weakness: it cannot distinguish "the thing did not happen" from "my description of the thing was wrong". A positive assertion is self-checking — write the path wrong and it fails immediately, loudly, on the very first run. A negative assertion written against a wrong path passes on the first run and every run after it, and it keeps passing after the cancellation endpoint starts being called in error, because the pattern it watches never described that endpoint in the first place. Concretely: `never()` on `request().withPath("/catalogue/v1/hold/H-88213")` — singular `hold` — is green forever. Nothing in the test, the build or the report distinguishes it from a correct assertion. The scoping that makes `never()` useful is exactly what makes it fragile. ## Making a negative assertion trustworthy 1. Build the request definition once, in a shared helper or constant, and use the very same object in a test where the call *is* expected. If the path is wrong, that positive test fails and tells you. 2. Where the claim really is "no traffic at all", prefer `verifyZeroInteractions()`. It has no pattern, so it has no pattern to get wrong. 3. Prove the negative can fail: temporarily make the code under test send the request and confirm the assertion goes red. A negative assertion nobody has ever seen fail is unverified test code. 4. Pair the negative with a positive on the same run wherever you can — "the availability read happened once and the cancellation never did" is a far stronger statement than either half alone. ## What neither one proves - Neither says anything about traffic that went somewhere else. A client pointed at a different host, port or base URL leaves this journal empty, and `verifyZeroInteractions()` then passes for entirely the wrong reason. - Neither knows whether an expectation matched. The journal records arrivals, so a request that no expectation answered is still an interaction and still fails `verifyZeroInteractions()`. - Neither covers work that happens after the assertion runs. An asynchronous cancellation dispatched a moment later is not in the journal yet, so both negatives pass and the defect ships. ## Choosing between them in practice - Use `never()` when other traffic to the same server is expected and legitimate, which is the common case in an integration test that exercises several endpoints. - Use `verifyZeroInteractions()` when the whole point of the test is that no call was made — a cache hit, a short-circuit on invalid input, a disabled feature. - Use `never()` with a deliberately broad definition when "nothing on this endpoint" is the claim but other endpoints are in play. ## Pitfalls - Reading a green `never()` as evidence the server was untouched. That is `verifyZeroInteractions()`'s claim, not `never()`'s. - Passing a request definition to `verifyZeroInteractions()`. It takes none; if you need scope, you need `never()`. - Writing `atMost(0)` where `never()` reads better. They assert the same thing, and the named factory states the intent for the next reader. - Letting a negative assertion survive a refactor that renamed the endpoint. Nothing will tell you; the assertion simply stops meaning anything.