Mockito

No real code runs. Mockito returns the type's default value: null for objects, 0 for numbers, false for boolean, and an empty collection, Optional or stream for those types. Void methods do nothing. The call is recorded so you can verify it later.

@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.

Chain the answers: when(m.next()).thenReturn(1).thenReturn(2), or use the varargs shorthand thenReturn(1, 2). Calls consume answers in order. Once they run out, the mock keeps repeating the last answer forever — it does not reset, return null, or fail.

when(...) takes a value as its argument, and a void call produces no value, so the expression is not legal Java. Use the do-family instead: doThrow(new IllegalStateException()).when(service).delete(id) — behaviour first, stubbed call last.

Use thenAnswer instead of thenReturn: when(repo.save(any())).thenAnswer(inv -> inv.getArgument(0)). The lambda is an Answer that Mockito runs on every matching call, so the result is computed per call from the real arguments.

Write when(mock.method(args)).thenReturn(value), or thenThrow(exception) for a failure path. Anything you do not stub returns the type's default: null for objects, 0 for numbers, false for boolean, and an empty collection for collection-returning methods.

Use the do-family with a chain: doThrow(new IOException()).doNothing().when(mailer).send(any()). First call throws, later calls do nothing, because the last entry in the chain repeats. IOException must be declared by send(...) or Mockito rejects the stub.

Use eq() only when the same call already uses another matcher, because matchers and raw values cannot be mixed. If no argument needs a wildcard, pass plain values - eq() everywhere is noise with identical behaviour.

An ArgumentCaptor grabs the actual argument a mock received so you can assert on it. Create it with ArgumentCaptor.forClass(X.class) or @Captor, pass captor.capture() inside verify(...), then read captor.getValue() and assert normally.

A matcher is a placeholder used inside Mockito's when() or verify() saying 'any argument fitting this description' instead of one exact value. any() matches anything, anyString() any non-null String, anyInt() any int. Use them when the value is irrelevant or unpredictable.

Matchers do not return values you pass in. Each one pushes a matcher object onto a thread-local stack and returns a dummy (0, false, null). Mockito only sees dummies, so per call all arguments must be matchers or none. Wrap literals in eq().

Use argThat(ArgumentMatcher) with a predicate: verify(repo).save(argThat(o -> o.total() > 100 && o.status() == PENDING)). ArgumentMatcher is a functional interface with one boolean matches(T) method, so a lambda works. It composes with the built-in matchers in the same call.

Create an ordering handle with InOrder inOrder = inOrder(mock), then call inOrder.verify(mock).open() followed by inOrder.verify(mock).write(...). Plain verify() only checks that each call happened at all; it ignores sequence, so it passes even if write ran first.

Use verify(mock).method(args) - it asserts exactly one matching call. For other counts pass a mode: verify(mock, times(3)).method(args). Arguments match by equals or by matchers. A mismatch throws an assertion error showing wanted versus actual invocations.

Use verifyNoInteractions(mock) - it fails if any method at all was called on that mock. Asserting one method was not called is verify(mock, never()).method(args), which is scoped to that method and those arguments and says nothing about the rest of the mock.

timeout(ms) wraps the verification mode in a retry loop: Mockito re-checks the mock's recorded calls about every 10 ms until the check passes or the budget expires, then rethrows the last failure. It returns the moment it succeeds, so the number is an upper bound, not a sleep.

timeout(200) polls and returns as soon as the verification passes, so it is an upper bound. after(200) always waits the whole 200 ms and only then asserts, so it can catch extra or late calls that timeout would have already passed over.

The mock's default answer decides. Mockito's built-in default, Answers.RETURNS_DEFAULTS, gives 0 for numeric primitives, false for boolean, an empty collection, Optional or Stream for those types, and null for every other object. Nothing throws.

It makes a mock auto-create and cache a mock for each mockable return type, so chained calls like when(a.getB().getC()).thenReturn(x) work instead of throwing NullPointerException on the second link. Enable with @Mock(answer = Answers.RETURNS_DEEP_STUBS) or mock(A.class, RETURNS_DEEP_STUBS).

The classic mock maker generates a runtime subclass and overrides methods, and Java forbids subclassing a final class or overriding a final method. The inline mock maker instead attaches a Java agent and rewrites the loaded class's own bytecode, so no subclass is needed.

Mockito.mockConstruction(Foo.class) opens a scope in which every new Foo(...) on the current thread returns a Mockito mock instead of a real object, and the real constructor body never runs. Closing the scope restores normal construction.

Open Mockito.mockStatic(TheClass.class) in a try-with-resources block; inside it, stub with mocked.when(TheClass::method).thenReturn(value). While the scope is open all static methods of that class are mocked on the current thread, and closing the scope restores the real implementations.

It means a stubbing you declared was never matched by any call during the test. Under strict stubbing Mockito reports it after the test, pointing at the stubbing's line. The fix is usually to delete the stubbing or move it into the test that actually needs it — not to switch strictness off.

Mock the boundary: collaborators that leave the process or are slow, nondeterministic or hard to set up (repositories, HTTP clients, clocks, message publishers). Construct everything else for real: value objects, DTOs, enums, collections, pure helpers. Real is the default; a mock needs a reason.

Mockito.mock() is only a mechanism. Stubbing with when/thenReturn puts the object in a stub role: it supplies input and your assertion checks the result. verify() puts it in a mock role: the call itself is the thing being asserted. Pick one role per collaborator.

LENIENT does no stubbing checks (old Mockito 1.x behaviour). WARN only logs hints about unused or mismatched stubbings. STRICT_STUBS fails the test: a stubbing that was never used is an error, and calling a stubbed method with arguments matching no stubbing fails at the call site instead of returning null.

It fires when the code calls a mock method that IS stubbed, but with arguments matching none of its stubbings. Mockito fails right at that call, showing stubbed versus actual arguments. Previously the call silently returned null, so the test failed later with an unrelated NullPointerException.