You inherit a Mockito test suite where most tests spy on the class under test and stub out a few of its own methods. What risks does that carry, and when is stubbing a real object's own method still the right call?

## What the suite is actually doing A test that spies the class under test and stubs some of its methods is running a **partial mock**: real behaviour everywhere except the methods you replaced. The appeal is obvious — one method is inconvenient (it hits disk, sleeps, reads the clock, calls a static factory), so you stub it and test the rest. The cost is less obvious, which is why suites accumulate this pattern. ## The four risks, in order of severity **1. Stub drift and false greens.** This is the serious one. Suppose `computeFee()` is stubbed to return `10` because computing it is awkward. Six months later `computeFee()` changes its rounding, or starts throwing on negative input. The stub still returns `10`, the test still passes, and the suite reports that the class works — while production behaves differently. Unlike a mocked *collaborator*, where the contract is a published interface you can reason about, a stubbed *self-method* is a private implementation detail with no contract to anchor it. Nothing pushes the stub back into agreement with reality. **2. Coverage illusion.** Line coverage tools count the stubbed method as covered if any other test touches it, and the test's name still claims to test the class. Reviewers reading `orderServiceTest.placesOrder()` reasonably assume the whole path was exercised. Auditing what a suite really covers becomes a manual exercise. **3. Coupling to the internal call graph.** Stubbing `enabled()` to steer `run()` is an assertion that `run()` calls `this.enabled()`. That is not behaviour; it is structure. Inlining `enabled()`, renaming it, changing it to take a parameter, or reducing it to `private` all break the test while the class's observable behaviour is unchanged. In a codebase that refactors regularly, this converts every restructuring into test archaeology, and the usual response — reshaping the code to keep the tests happy — is precisely backwards. **4. Mechanism traps.** `private` methods cannot be stubbed at all, so the pattern pushes people to widen visibility "for testing", weakening encapsulation. On Mockito 2–4's default subclass mock maker, `final` methods were silently not stubbed — the stub was accepted and ignored, and the real method ran — producing failures that look impossible until you check the modifier. Mockito 5's inline mock maker handles final, but the private case never goes away. ## What the pattern is telling you The pull toward partial mocking almost always signals **two responsibilities in one class**: the logic you want to test, and an environmental dependency hard-wired into a method. The structural fix is to make that dependency explicit — inject a `Clock` instead of calling `System.currentTimeMillis()`, an `IdGenerator` instead of `UUID.randomUUID()`, a `ConfigLoader` instead of reading the file inline, a `Sleeper` instead of `Thread.sleep`. Then the class is testable with plain mocks, the test no longer knows the internal call graph, and the design is better independently of testing. That reframing is the answer an interviewer is listening for: the spy is not the problem, it is the symptom. ## When it is genuinely the right call **Legacy under a deadline.** You need a class under test *today* and cannot restructure it safely without tests — the classic chicken-and-egg. Spying to stub the one untestable method is a legitimate seam that gets you a safety net, after which you refactor and delete the spy. Write that intent down in the test, because otherwise the temporary becomes permanent. **Template-method hooks.** In a framework base class, a `protected` hook is a *published extension point* — subclasses are supposed to override it. Stubbing it in a test targets a real contract, not an accident of implementation, so the coupling objection largely evaporates. **Expensive but behaviour-irrelevant setup.** A method that warms a large cache or builds a heavy fixture, whose result the test does not care about, can reasonably be neutralised — provided the test is not about that behaviour. ## How I would drive the inherited suite 1. **Inventory.** Count tests that spy the class under test and, for each, the number of stubbed self-methods. One is a smell; two or more is nearly always a class doing too much. 2. **Triage by risk.** Prioritise stubs on methods that carry business rules — those are the drift candidates that produce false greens. Stubs on `sleep`-like methods are comparatively harmless. 3. **Refactor at the source.** Extract the awkward dependency into a collaborator, inject it, replace the partial mock with a plain mock. Do this as you touch the code, not as a big-bang migration. 4. **Set the rule going forward.** New partial mocks of the class under test require a comment naming the reason and a ticket if it is legacy. Never stub the method the test is actually about. 5. **Do not ban it outright.** A blanket prohibition on a codebase with real legacy pushes people toward worse workarounds — widened visibility, test-only constructors, mutable statics. Bound it instead. ## The one-sentence version A partial mock of the class under test trades away part of what the test claims to verify and buys coupling to internal structure in return; sometimes that trade is worth making, but it should always be a deliberate, documented decision rather than the default.