Mockito exposes a MockitoSession API via Mockito.mockitoSession(). What is it for, how do you drive one by hand, and what breaks if you forget to finish it?

## What it is `MockitoSession` (`org.mockito.MockitoSession`, built via `Mockito.mockitoSession()`) is the primitive that all Mockito test integrations are built on. A session: 1. initialises annotated fields (`@Mock`, `@Spy`, `@Captor`, `@InjectMocks`) on the object you pass to `initMocks`, 2. installs a listener that enforces the chosen `Strictness`, 3. on completion, runs the validation that produces `UnnecessaryStubbingException` and Mockito's misuse diagnostics, 4. cleans up the thread-local state Mockito keeps between the two points. The JUnit 4 `MockitoJUnitRunner`, the `MockitoRule`, and the JUnit 5 `MockitoExtension` all do exactly this around each test; the session API is what you use when there is no such integration. ## Driving one by hand ```java public class TestNgOrderServiceTest { @Mock OrderRepository repo; private MockitoSession session; @BeforeMethod public void before() { session = Mockito.mockitoSession() .initMocks(this) .strictness(Strictness.STRICT_STUBS) .name(getClass().getSimpleName()) .startMocking(); } @AfterMethod public void after() { session.finishMocking(); } } ``` Builder options worth knowing: - `initMocks(Object...)` — one or more objects whose annotated fields should be initialised (useful when a base class also holds mocks). - `strictness(Strictness)` — the level; **STRICT_STUBS is the default for a session**, which is why hand-rolled sessions are the strict option by construction. - `name(String)` — a label that shows up in hint messages. - `logger(MockitoSessionLogger)` — redirect WARN-level hints somewhere other than stdout. `startMocking()` returns the `MockitoSession`; `finishMocking()` is mandatory and belongs in a `finally` or the framework's after-each hook so it runs even when the test fails. ## finishMocking(Throwable) The overload `finishMocking(Throwable failure)` exists for a specific ordering problem. Suppose a test fails on a genuine assertion, and it *also* left an unused stubbing behind. If you call the no-arg version, Mockito reports `UnnecessaryStubbingException`, which can replace or obscure the real failure — the developer chases a stubbing that was never the point. Passing the actual failure lets Mockito see that the test already failed, so instead of throwing its own exception it *decorates* the report with stubbing hints ("this stubbing was never used — it may explain the failure"). Test frameworks that integrate Mockito properly use this overload; hand-rolled integrations usually should too. ## What breaks if you forget finishMocking() - **The hygiene checks never run.** Unused stubbings and misuse go unreported, so a session you thought was STRICT_STUBS behaves like LENIENT for the end-of-test checks. (Argument-mismatch detection still fires during the test, because that listener is already installed.) - **State leaks.** Mockito keeps thread-local state for the open session; a subsequent test starting a new session can hit "unfinished session" style problems, and inline-mock-maker mock references stay reachable longer than necessary, which shows up as memory pressure in large suites. - **Failures land in the wrong test.** Anything Mockito would have reported at the end of test A can surface during test B, producing the classic "only fails when the whole class runs" report. The same discipline applies to `MockitoAnnotations.openMocks(this)`, which returns an `AutoCloseable` you are expected to close — though note that `openMocks` only initialises fields, it does not give you strictness. If you want hygiene checks without a JUnit integration, you want a session, not `openMocks`. ## When to actually use it In a JUnit 5 codebase, essentially never — the extension is strictly better and less code. Legitimate cases: - non-JUnit runners (TestNG, Spock, Cucumber steps with their own lifecycle), - a custom test base class or framework where you own the before/after hooks, - a test that needs two differently-configured mock scopes inside one method, though that usually means the test is doing too much, - teaching or debugging: reading the session API makes clear that strictness is a lifecycle concern, not a property of the mock object. In an interview, the useful signal is exactly that last point: the runner, rule and extension are conveniences over a session, so if you understand the session you can explain why bare `Mockito.mock(...)` can never enforce strict stubbing.