A codebase has accumulated dozens of tests that mock static methods with Mockito. As the technical lead, how would you decide where that is acceptable and where the code should change instead?
answer
- boundary tool, not a default
- inject Clock / Supplier<UUID> instead
- wrap third-party statics in an adapter you own
- costs: blast radius, thread-local, agent, coupling
- policy + lint on try-with-resources
basics
~20 sAllow it at boundaries you do not own — third-party or JDK statics, legacy code you cannot change. Discourage it in your own domain code, where injecting a Clock, an ID generator, or a thin adapter interface removes the need entirely, keeps tests fast and thread-safe, and makes the dependency visible in the API.
solid answer
~50 sI treat static mocking as a boundary tool with real costs: it mocks a class's entire static surface, is thread-local so async paths escape it, requires the inline mock maker's instrumentation, and couples tests to the fact that a specific static is called — which makes the suite refactor-hostile. So: acceptable for third-party or JDK statics we cannot inject around, for legacy code under a freeze, and as scaffolding for characterisation tests before a refactor. Not acceptable as the default way to test our own code, where the alternatives are cheap — inject a `Clock` instead of mocking `Instant.now()`, inject an ID supplier instead of mocking `UUID.randomUUID()`, wrap an awkward third-party static in a one-method adapter interface we own and mock that. Operationally I would inventory current usage, allow-list the boundary cases, require the try-with-resources form in review, and treat new occurrences in domain code as findings. The goal is not zero usage — it is that each occurrence has a reason nobody can remove.
go deeper
Say that if you can inject the dependency — a clock, an ID generator — do that, and reserve static mocking for code you cannot change.
Name the concrete alternatives and at least two costs, such as blast radius and thread-locality.
Weigh refactor risk against test value, propose adapters for third-party statics, and describe using it as temporary scaffolding.
Set an explicit policy with inventory, allow-list, lint enforcement and refactor tickets, and justify it with suite runtime and coupling, not taste.
## Why the question is a design question Mocking a static is always a workaround for a call site that cannot be substituted. The interesting decision is not "does Mockito support it" — it has since 3.4.0 — but whether the underlying coupling should exist. A static call is a hard-coded dependency on a specific implementation with no seam; that is precisely what makes it hard to test, and testability pain here is usually a proxy for real design constraints, such as inability to swap implementations, configure per environment, or reason about time and randomness. ## The concrete costs **Blast radius.** Activating the scope mocks every static on the class, so unstubbed helpers return nulls and failures appear far from their cause. **Thread-locality.** Only the registering thread is affected. Asynchronous production code silently runs the real static, producing tests that pass for the wrong reason or fail with confusing "wanted but not invoked" messages. **Lifecycle risk.** A leaked scope poisons later tests on the same thread; under parallel execution the damage is non-deterministic. **Instrumentation.** It needs the inline mock maker, which attaches a Java agent. That interacts with coverage tooling, security-restricted environments, and newer JDK agent-loading warnings, and it is slower than plain mocks. **Coupling.** The test asserts "this static is called", not "this behaviour is produced". Refactoring the implementation breaks tests that should not care. ## The cheaper alternatives **Time.** Inject a `java.time.Clock`; use `Clock.fixed(instant, zone)` in tests. The JDK added `Clock` for exactly this reason, and `Instant.now(clock)`/`LocalDate.now(clock)` accept it. **Randomness and identity.** Inject a `Supplier<UUID>` or an `IdGenerator` interface. Production wires `UUID::randomUUID`. **Third-party statics.** Wrap in a one-method adapter interface you own. The rest of the codebase depends on your interface; one thin integration test covers the real library. This also insulates you from library upgrades. **Your own utility statics.** If a static needs mocking, it is doing something that is not a pure function. Pure statics — formatting, parsing, arithmetic — never need mocking; you just call them. The urge to mock a static is a good detector of hidden I/O or hidden state. ## Where I would genuinely allow it - JDK or third-party statics with no injectable alternative and no reasonable wrapper. - Legacy modules under a change freeze, where a characterisation test today is worth more than a perfect design later. - Neutralising catastrophic statics in tests — something that exits the JVM, writes to a real filesystem path, or fires a real network call. - Short-lived scaffolding while a refactor is in flight, with the removal tracked. ## Making the policy stick A policy is only real if it is visible. I would: inventory current usages and their reasons; write the rule down (allowed at boundaries, discouraged in the domain, always try-with-resources); enforce the resource form with static analysis, since the leak class of bug is mechanical; and pair each remaining domain usage with a small refactor ticket. I would also watch the suite's runtime — instrumented tests are measurably slower — and use that number rather than taste to argue the case. ## The nuance to voice in an interview The absolutist position "never mock statics" is easy to say and wrong in practice: real systems have boundaries you cannot redesign, and a pragmatic scoped mock beats no test at all. The useful position is that every occurrence should have an owner and a reason, and that the count should trend down in code you control, because the same seams that remove the need for static mocking also give you configurability, testable time, and cleaner dependency graphs.
- What do you replace `Instant.now()` with so the test never has to mock a static?Inject a java.time.Clock into the class and call Instant.now(clock). Production supplies Clock.systemUTC(); the test supplies Clock.fixed(...) or a mutable test clock to advance time deliberately. Time becomes an explicit dependency, tests become deterministic without instrumentation, and you gain the ability to simulate time travel in tests.
- Why can a wrapper interface around a third-party static be better than mocking that static directly?The wrapper is a type you own, so plain Mockito mocks it with no instrumentation, no thread-local scoping, and no blast radius over other statics. It also narrows the surface your code depends on, so a library upgrade or replacement touches one class. The cost is one thin class plus an integration test that exercises the real library.
Mocking a static is like taping over a smoke detector to cook: sometimes the only option in someone else's kitchen, but if you do it in your own every night, the kitchen needs a vent, not more tape.
saying these in an interview costs you the question
- Declaring that mocking statics is always wrong, with no allowance for third-party boundaries.
- Treating it as the normal way to control time or randomness in your own code.
- Ignoring that the whole static surface of the class becomes mocked.
- Overlooking the thread-locality limitation when the system under test is asynchronous.
- Proposing a policy with no inventory or enforcement, so nothing changes.