Mocks, Spies & Injection

@Mock is only metadata; something must scan the test instance and assign the mocks. Enable one initializer: @ExtendWith(MockitoExtension.class) on JUnit 5, MockitoAnnotations.openMocks(this) in a setup method, or the JUnit 4 MockitoJUnitRunner/MockitoRule. Without one, the fields stay null.

@InjectMocks makes Mockito create a real instance of that field's type and push the test class's @Mock and @Spy fields into it as dependencies. The field under test is a real object, not a mock — only its collaborators are mocks.

On a mock, an unstubbed method does nothing and returns a default — null, 0, false, or an empty collection. On a spy, an unstubbed method runs the real implementation. Both record calls, so both can be verified.

Both create the annotated mocks per test. The extension additionally applies strict stubs (failing on unused or mismatched stubbings), validates Mockito usage after each test, closes the session for you, and can inject mocks as test-method parameters. openMocks does none of that but works in any framework and needs no extra artifact.

Mockito tries constructor injection first, then property setter injection, then direct field injection, and stops at the first strategy that works — it does not combine them. For constructors it picks the one with the most parameters and resolves each argument by type, passing null for anything it cannot match.

Because when(spy.loadData()) has to evaluate spy.loadData() to record the stub, and on a spy that runs the real method — with its side effects, cost, or exceptions. Use doReturn(value).when(spy).loadData(), which registers the stub without ever invoking the real method.

Injection failures are silent, so work through the causes: the wide constructor won and setter/field injection never ran; the field is final or static; two dependencies share a type and names do not match; or annotations were never processed. The reliable fix is to construct the object explicitly in the test.

Two forms produce the same kind of object: the programmatic Mockito.mock(Foo.class) (optionally with settings) and the declarative @Mock Foo foo; field. The annotation is shorter, names the mock after the field for better failure messages, and needs an initializer to run; mock() works anywhere, including inside a method or with generics.

No constructor runs and no field initializer runs. Mockito generates a subclass (or, with the inline mock maker, instruments the class) and allocates an instance without calling any constructor, using Objenesis. All fields stay at their JVM defaults, and every method is intercepted, so no real code executes.

The ones that earn their keep: name(...) for readable failure messages, defaultAnswer(...) to change what unstubbed calls return, lenient() to exempt one mock from unused-stub checking, extraInterfaces(...) when code casts the collaborator to another type, plus serializable(), stubOnly() and verboseLogging() for narrower cases.

Yes — @Spy fields join @Mock fields in the injection pool, so a spied collaborator is injected like any mock. Putting @Spy and @InjectMocks on the same field means the object under test is itself wrapped as a spy after its dependencies are injected, making it a partial mock.

If you initialize the field yourself, Mockito spies that instance. If you leave it uninitialized, Mockito instantiates the type using a no-arg constructor (private is fine) and spies that. It fails for interfaces and abstract types with no instance, and for types with only argument-taking constructors — initialize those inline.

Closing ends that mocking session and releases the mocks Mockito is holding. With the inline mock maker every mock is kept in a global registry until released, so never closing means mocks and everything they captured stay reachable across thousands of tests — growing memory, sometimes to OutOfMemoryError. initMocks returned nothing, which is why it was deprecated in favour of openMocks.

Mockito creates a new instrumented instance of the same class and shallow-copies the original's fields into it. Mutations through the spy therefore never reach the original object. Real method bodies execute on the spy, so this is the spy and self-calls are intercepted and stubbable.

@InjectMocks saves boilerplate on wide constructors but resolves wiring reflectively and fails open, so constructor changes rot tests silently. Manual construction costs one line and turns those changes into compile errors. Most large codebases end up preferring explicit construction, with the annotation tolerated for wide legacy constructors.

Every stubbed method is behaviour no longer under test, and the stub encodes the class's internal call graph — so refactoring breaks tests that assert nothing, and stubs drift from the real implementation while staying green. It is still justified for legacy classes you cannot yet restructure and for genuine template-method hooks.

Both are JUnit 4 Mockito integrations: they initialize annotated mocks, validate Mockito usage after each test, and by default detect unused stubbings. The rule exists because a class can have only one runner, so the rule leaves that slot free for another runner. Under JUnit 5 both are ignored silently, leaving mocks null.

Deep stubs make every object-returning method return another deep-stub mock, remembered per call, so when(a.getB().getC()).thenReturn(x) works without stubbing each level. It is convenient for hostile third-party APIs, but a chain you must deep-stub usually signals a Law-of-Demeter violation in your own code.