What does Mockito's doCallRealMethod() do, and how does using it on a plain mock differ from creating a spy over a real instance?

## The two ways to get partial mocking Mockito gives you two routes to an object where *some* methods are real and some are faked, and they differ in their default. **Spy** — real by default, fake where stubbed: ```java OrderService spy = spy(new OrderService(repo)); doReturn(0).when(spy).discount(); // only this is faked ``` **Mock plus `doCallRealMethod()`** — fake by default, real where you say so: ```java OrderService mock = mock(OrderService.class); doCallRealMethod().when(mock).total(); // only this is real ``` The second is the safer default for a class with dangerous methods, because nothing real runs unless you opt in method by method. ## Construction is the decisive difference A Mockito mock is not built by calling a constructor. The mock maker generates or instruments a type and instantiates it through Objenesis, bypassing constructors entirely. Consequences: - Every instance field is at its JVM default: `null` for references, `0`/`false` for primitives. - Field initialisers and constructor logic never run. - Collaborators injected through the constructor are `null`. So a real method invoked via `doCallRealMethod()` executes against an uninitialised object. If it reads `this.repository`, you get an NPE thrown from production code, and the stack trace looks alarming until you remember why. There is a partial workaround — `mock(Foo.class, withSettings().useConstructor(args))` runs a real constructor — but it is fiddly and rarely worth it. A spy is different: you construct the object yourself, and Mockito creates the proxy and **copies the real object's fields into it**. State is present, so real methods behave normally. Note the copy semantics: the spy is a distinct object, so mutations made through the spy do not appear on your original instance, and any code holding a reference to the original will not see stubbed behaviour. ## Where doCallRealMethod genuinely fits **Abstract classes and template methods.** You want to test the concrete algorithm in an abstract base without writing a test subclass: ```java AbstractImporter importer = mock(AbstractImporter.class); doCallRealMethod().when(importer).importAll(any()); doReturn(List.of(row)).when(importer).readRows(any()); ``` `importAll` runs for real and its abstract hooks are stubbed. Whether this beats a small hand-written test subclass is a taste call — the subclass is usually clearer, but the mock avoids maintaining another class. **Default interface methods.** A `default` method that composes other interface methods can be exercised the same way, with the abstract members stubbed. **Pinning legacy code before refactoring.** For a class you cannot restructure yet, opting exactly one method into real behaviour gives you a characterisation test without the risk that a spy's other real methods do something destructive. ## What it does not solve `doCallRealMethod()` on a method that depends on constructor-injected collaborators will fail, and no amount of stubbing the *other* methods helps, because the failure is a null field, not a call. Likewise, static and final concerns are mock-maker questions, not something this API addresses. ## Interaction with verification An invocation that runs the real body is still recorded, so `verify(mock).total()` works exactly as usual. What is *not* recorded reliably is what the real body calls on itself — internal self-invocation dispatch is an implementation detail you should not build tests on. ## Design perspective Every partial mock is an admission that the class under test contains a piece you want to run and a piece you want to suppress. Occasionally that is unavoidable — a framework base class, a third-party type, legacy code under characterisation. Usually it means the suppressed piece is a separate responsibility that wants to be a collaborator: extract it behind an interface, inject it, and the test becomes a plain mock with no partial-mocking machinery at all. Mockito's own documentation carries this warning, and it is worth repeating in an interview: reaching for `doCallRealMethod()` twice in the same test is a design signal, not a technique to master. ## Summary `doCallRealMethod()` opts one method of an otherwise-inert mock into real behaviour. Because the mock was created without a constructor, that method must be effectively stateless to work. A spy inverts the default and carries real state, which makes it more forgiving and more dangerous at the same time. Both are partial mocking; both are a last resort behind restructuring the class.