Mockito (Mocking)

A MockedStatic only intercepts static calls made on the same thread that created it. Code under test that runs the static call on a different thread (a thread pool, an async task) sees the real method, not your stub.

Mockito tries constructor injection, then setters, then fields. It matches mocks by type; if several mocks have the same type it falls back to matching the field name. Anything it can't match is left null.

Mockito generates the mock at runtime by subclassing the type (using ByteBuddy) and overriding its methods. The default subclass approach can't override final classes/methods or static methods. The newer inline mock maker (default in Mockito 5) can mock final and static via mockStatic.

Mock collaborators that are slow, external, non-deterministic, or hard to set up (databases, HTTP, clocks). Use the real object for simple value or pure-logic dependencies. Over-mocking couples tests to implementation details and can hide real integration bugs.

You can only stub a checked exception that the method actually declares with throws. Unchecked exceptions (RuntimeException/Error) are always allowed. Otherwise Mockito fails with "Checked exception is invalid for this method!".

thenReturn gives a fixed value computed once. thenAnswer runs your code on every call, so you can build the return value from the actual arguments — useful when the answer depends on what was passed in.

InOrder lets you assert calls happened in a specific sequence. You create inOrder(mockA, mockB), then call inOrder.verify(...) in the order you expect; Mockito checks the calls occurred in that relative order.

verifyNoInteractions(mock) asserts the mock was never used at all. verifyNoMoreInteractions(mock) is called after your verify() calls and asserts there were no leftover, unverified interactions beyond those.

Using any() for every argument makes tests pass even when the code passes wrong values, so bugs slip through. Match the arguments that carry the test's intent with eq()/argThat, relax only the truly irrelevant ones, and capture when you need detailed checks.

Reaching for static mocks usually means your code calls hard-coded global things (clocks, randomness, static singletons) it can't swap out for tests. Injecting those as parameters or interfaces makes the code testable with plain mocks and removes the need.

Avoid @InjectMocks when wiring is ambiguous or hidden — instead just call new Service(mock1, mock2). If you can't construct it cleanly, your production code probably relies on field injection or has too many dependencies, which is a design smell.

Use a mock by default to fully isolate a dependency. Reach for a spy only when you need most of an object's real behavior but want to override or verify a small part. Lots of spies usually means a class is hard to test and probably doing too much.

Strict stubbing (the default now) flags stubs your test never used and warns when you call a stubbed method with arguments that don't match what you stubbed. It catches dead and mismatched stubs that the old lenient mode silently ignored.

Given = set up the mocks with given().willReturn(). When = call the method you're testing. Then = check results with assertions and then(mock).should() verifications. BDDMockito's method names match those three section labels.

Pick one style per test (or per codebase) and stay consistent. Don't mix given() with verify() in the same test. Remember void stubbing flips order. Otherwise it behaves exactly like normal Mockito, so there are no new runtime risks.

Chain stubs: when(mock.call()).thenThrow(new TimeoutException()).thenReturn(value). The first call throws, later calls return. Use thenAnswer/doAnswer when whether (or what) to throw depends on the actual arguments.

Captors can record nothing if the call didn't happen, return the wrong value with multiple calls, fail with NPE if @Captor isn't initialized, and capture references (not snapshots) of mutable objects. Overusing them couples tests to internal details.