With a Mockito mock created using RETURNS_DEEP_STUBS, how do you verify an interaction on the last object of a call chain, and why are invocation counts on the intermediate objects untrustworthy?

## Why leaf verification works at all A deep stub caches the child mock it creates for each invocation. So when your test writes `verify(config.getServer()).restart()`, the argument `config.getServer()` is evaluated first and returns the *same* mock instance the production code received. `verify(...)` then wraps that child, and `.restart()` is checked against its recorded invocations. Nothing special is happening: you are verifying an ordinary mock that you happened to obtain by navigating. The readable form is to name it: ```java Server server = config.getServer(); verify(server).restart(); verify(server).setPort(8080); ``` This also stops you from re-traversing the chain once per assertion. ## Why the links are polluted The traversal itself is a method call on the parent mock, and Mockito records *every* call on a mock — it cannot distinguish "the test navigating" from "the system under test collaborating". A typical deep-stub test therefore calls `config.getServer()` at least three times: once while stubbing, once (or more) inside the production code, and once inside each `verify(...)` argument. The consequences: - `verify(config, times(1)).getServer()` fails, or passes only by coincidence, and the number changes when you add an assertion — an assertion whose result depends on how you wrote your other assertions is worthless. - `verifyNoMoreInteractions(config)` is essentially unusable, because the mock has recorded your test's navigation calls plus the auto-created stubbings. - `verify(config, never()).getServer()` can only be trusted if the chain is never navigated in the test either, which defeats the point. - Argument-sensitive links compound this: `repo.find("a")` and `repo.find("b")` are different invocations with different children, so a count on `find` mixes populations you probably meant to separate. A related sharp edge: you cannot verify "the chain was navigated" and "the leaf was called" as one atomic fact. Mockito has no notion of a chained interaction; it has a parent with recorded calls and a child with recorded calls. ## Interaction with strictness Under `MockitoExtension` with the default `Strictness.STRICT_STUBS`, stubbing a chain that the code under test never fully exercises reports `UnnecessaryStubbingException`, because the leaf stubbing was never used. That is correct and useful, but it means a partially exercised chain surfaces as a strictness error rather than a plain assertion failure — confusing the first time you see it. Argument mismatch behaves the same way: stub `find("a")`, call `find("b")`, and you get a fresh unrelated child mock plus a strict-stubs complaint, not an obvious failure at the point of divergence. ## What to do instead The honest reading is that deep stubs are a *stubbing* convenience, not a *verification* tool. Use them to get data into the system under test, and assert on outcomes — the returned value, the state change, the single interaction with the real collaborator you care about. When a test genuinely needs to assert how many times an intermediate object was requested, the object graph traversal is behaviour you are testing, and the right move is to inject that collaborator directly rather than mock your way down to it: ```java // instead of deep-stubbing config.getServer().restart() new Restarter(server).restart(); // server injected, verify(server).restart(); ``` That also removes the strict-stubs noise and makes the test independent of the graph's shape.