You take over a large legacy Java test suite where Mockito mocks are configured leniently and stubbing hygiene has drifted. How would you decide on a strictness policy and roll it out without stalling delivery?

## Framing the decision This is not a technical question with one right answer; it is a policy question about where a team wants to pay. Lenient tests are cheap to write and expensive to trust: dead stubbings mislead readers, and silent `null` returns from argument mismatches turn a one-line diagnosis into a debugging session. Strict tests are the reverse — occasional friction while writing, sharp diagnostics forever after. For a suite that a team will keep for years, strict wins; for code being deleted next quarter, the migration is not worth funding. ## Step 1 — establish the destination and the exception rule Write it down in one sentence: *the default is `Strictness.STRICT_STUBS`; relaxations must be as narrow as possible and carry a reason.* Without a written destination, every migration stalls at WARN, which is the worst of both worlds — the checks exist but nobody acts on them. The exception ladder, narrow to broad: - `lenient().when(...)` on one stubbing — the normal escape. - `@Mock(lenient = true)` / `withSettings().lenient()` — a fixture collaborator legitimately used by only some tests. - `@MockitoSettings(strictness = LENIENT)` on the class — allowed only as a temporary marker with a ticket. ## Step 2 — measure before you enforce Running the suite at WARN produces the full inventory without breaking anyone. Two categories come out: - **Unused stubbings** — mostly harmless clutter, but the count tells you the size of the job and points at the fixtures that need redesign. - **Argument mismatches** — these deserve individual attention. A mismatch means production code called a collaborator with arguments the test author did not expect, and the test passed anyway on a `null`. A non-trivial share of these are genuine bugs or genuinely stale tests. That second bucket is also the business case: it turns "we want cleaner tests" into "here are N places where the suite was asserting nothing". ## Step 3 — sequence the rollout Big-bang flips fail on review load and merge conflicts. Better sequencing: - **Per module or per package**, starting with the code under active development, so cleanup rides along with work people are already doing. - **New code first**: make the strict harness the default in whatever templates, base classes or archetypes new tests come from, so the problem stops growing on day one. - **Leave the worst module for last** — usually the one with a giant shared fixture — because fixing it is a fixture-design job, not a strictness job, and conflating the two makes the migration look more expensive than it is. ## Step 4 — fix versus silence The discipline that makes or breaks this: when a strict-stubs failure appears, the first question is *why* the stubbing is unused. Typical answers and their correct responses: - The stubbing is genuinely dead → delete it. - Production code changed and no longer calls that collaborator → the test is stale; update the assertions, do not just delete the line. - A `@BeforeEach` stubs everything for a family of scenarios → move stubbing into the tests that need it, or extract small named helpers (`givenUserExists(...)`) that stub on demand. - One collaborator is genuinely shared and optional → mark that mock lenient, with a comment. If the team's default response is `lenient()`, the migration produces no value and a lot of noise. That is worth stating explicitly when you introduce the policy. ## Step 5 — make the harness itself the enforcement point Strictness is only real where a runner, rule, extension or session brackets the test. A suite that mixes `@ExtendWith(MockitoExtension.class)` with bare `Mockito.mock(...)` calls has unenforced pockets no policy statement covers. Practical enforcement options: a lint/ArchUnit-style rule that mock-using test classes must use the extension, a shared base class or composed annotation for the harness, and code review on any newly added class-wide LENIENT. ## Step 6 — accept the costs honestly - Strict stubbing makes some legitimate patterns noisier, especially parameterized tests where each parameter set uses a different subset of a shared fixture. Per-mock leniency is the intended answer there, not a reason to abandon the policy. - Mocks managed by other frameworks (for example Spring-created test doubles) sit outside the Mockito extension's session, so the policy simply does not reach them; do not promise coverage you cannot enforce. - The payoff is diagnosability and reader trust, which shows up as reduced debugging time rather than as a metric on a dashboard. Say that plainly instead of over-claiming a defect reduction. ## What a strong answer sounds like Destination stated in one sentence, WARN used as measurement rather than as a resting place, module-by-module sequencing tied to active work, an explicit narrow-escape ladder, and honesty about the fixture-design work hiding behind most of the failures.