What does Mockito's Answers.CALLS_REAL_METHODS do to a mock, and how does the resulting object differ from one created with Mockito.spy(existingInstance)?

## The mechanism `Answers.CALLS_REAL_METHODS` is a default answer whose implementation simply calls `invocation.callRealMethod()`. So on a mock created with it, an invocation that matches no stubbing executes the actual bytecode of the class, and one that does match returns the stubbed value. That is *partial mocking*. The crucial detail is how the instance came to exist. Mockito does not call your constructor: it creates the mock instance through Objenesis (a library that allocates an object without running a constructor). Every field therefore holds its JVM default — `null` for references, `0`/`false` for primitives — and any constructor-established invariant is absent. A real method that does `this.repository.find(id)` will throw `NullPointerException`, and the test author sees a confusing failure inside a class they thought they were exercising normally. ## Versus spy(instance) `Mockito.spy(realObject)` also produces a partial mock, but you supply a fully constructed object. Mockito creates its proxy and then **copies the fields** of your instance into the proxy. Consequences: - state is real; constructor logic already ran; - the proxy is a *different object* from the one you passed — self-calls inside the real code go through the proxy (so they are intercepted), but any reference to the original instance held elsewhere is not the spy; - mutations made through the spy do not appear on the original instance you handed in. Asserting on the original after acting on the spy is a classic bug. `Mockito.spy(SomeClass.class)` is the class-taking overload: it constructs an instance using the no-arg constructor and spies on it, which unlike `CALLS_REAL_METHODS` does run initialisation. Rule of thumb: `spy(instance)` when you need real state; `mock(Type.class, CALLS_REAL_METHODS)` when you want real *behaviour* with no state, typically for abstract classes or pure functions. ## The when() trap Both forms share a hazard. `when(partial.compute()).thenReturn(3)` evaluates `partial.compute()` for real before `when` ever sees it — which may throw, mutate state, or hit I/O. The safe form is the `doReturn` family, which never invokes the method: ```java doReturn(3).when(partial).compute(); doThrow(new IllegalStateException()).when(partial).validate(); doNothing().when(partial).flush(); ``` This is the single most-asked follow-up on the topic. ## Abstract classes and template methods The canonical legitimate use is testing an abstract class's concrete logic without writing a test subclass: ```java AbstractJob job = mock(AbstractJob.class, CALLS_REAL_METHODS); doReturn(List.of("a", "b")).when(job).fetchItems(); // the abstract hook job.run(); // real template method ``` Here the absence of constructor state is usually fine, because the class's dependencies are provided through the abstract hooks you stub. ## Limits imposed by the mock maker Partial mocking only intercepts what the active mock maker can intercept. Under the subclass mock maker, `private` and `static` methods, and `final` methods, run their real implementation and cannot be stubbed — including *self-calls* into a final method. The inline mock maker (the default since Mockito 5) removes the final-method restriction; `private` and `static` remain outside ordinary partial mocking. Also, real methods that were never designed for a half-initialised object are precisely where `CALLS_REAL_METHODS` bites. ## Design judgment The Mockito documentation itself flags partial mocks as a code smell in most situations: needing to stub part of a class under test usually signals that the class has two responsibilities and the stubbed part wants to be a collaborator. Legitimate uses cluster around code you cannot restructure — legacy classes, abstract base classes in a framework, and third-party types. In an interview, naming the smell and then giving the narrow legitimate cases is the answer that lands.