You own a Java codebase whose tests must also run in environments where bytecode instrumentation is unavailable or restricted. How do you decide how far to let the test suite depend on Mockito's instrumentation-based mocking?
answer
- inline = final/static/constructor capability
- Android, native image, agent-restricted JVMs lack it
- tag instrumented tests, keep a subclass-maker CI job
- wrap final vendor types behind your own interface
- JEP 451: dynamic attach on a deprecation path
basics
~20 sTreat instrumentation-only mocking as a capability with a cost. Keep the inline maker as the default, but confine tests that need final-type, static or constructor mocking to a tagged subset, and make sure the core suite runs green under the subclass maker so restricted environments stay viable.
solid answer
~50 sInstrumentation-only features — mocking `final` types, static methods, constructors — are the difference between the inline and subclass mock makers. Environments that cannot instrument (Android's runtime, some native-image and hardened-JVM setups, and eventually JVMs that disallow dynamic agent attachment) can still run the subclass maker, but every test relying on those features fails there. My approach: 1. **Default to inline** — it is Mockito 5's default and the capability is genuinely useful. 2. **Load the agent at startup** (`-javaagent` with `byte-buddy-agent`) so nothing depends on dynamic attach. 3. **Treat instrumentation-only tests as a marked minority**, tagged so they can be excluded, and keep a periodic CI job that runs the rest under `mockito-subclass` to prove the fallback still works. 4. **Prefer design over instrumentation**: wrap a final third-party client behind your own interface, inject a `Clock`, pass factories instead of mocking constructors. The point is that mocking a final third-party type is a *coupling decision*, not just a tooling one.
go deeper
Know that the inline maker is what makes final and static mocking possible and that some environments cannot use it.
Name the alternatives — mockito-subclass, extension resource, per-mock MockMakers — and one design refactoring that avoids the need.
Contain the dependency: tag such tests, wire the agent at startup, and keep the fallback verified in CI.
Own the policy end to end — platform reach, review pressure toward seams, explicit repository-wide maker choice, and a migration story for JEP 451.
## Framing the decision The inline mock maker is a capability: it lets tests intercept code that the language deliberately made non-overridable. Every use of that capability creates a dependency on the JVM permitting instrumentation. The strategic question is not "is the inline maker good" — it is the default for good reason — but *how much of your suite is allowed to require it*. Three forces push on the answer. **Platform reach.** Android's runtime does not support the JVM instrumentation API in the same way, so unit tests there historically use the subclass maker. GraalVM native-image test execution and certain hardened or containerised JVMs restrict agents. And JEP 451 has put dynamic agent attachment on a path to being disallowed by default; a suite that self-attaches today may need explicit configuration tomorrow. **Design feedback.** Needing to mock a `final` third-party class, a `static` factory, or a constructor is usually the test telling you that your code binds directly to something it does not own. Introducing a narrow interface you control — a port around the SDK client, an injected `Clock`, a factory parameter instead of `new` — removes the need for instrumentation *and* removes the coupling. That refactoring pays twice, and it is the answer an interviewer is listening for. **Pragmatism.** Sometimes the coupling is not worth removing: a one-off legacy path, a vendor type used in a single adapter, a static utility in code you are about to delete. Spending design effort to avoid one `mockStatic` block is not automatically right. ## A workable policy 1. **Inline maker is the classpath default**, wired with `-javaagent` on the byte-buddy agent so no dynamic attach happens and the JDK warning never appears. 2. **Instrumentation-only tests are tagged** — a JUnit `@Tag("instrumented")` or an equivalent naming convention — so a build can exclude them with one flag. 3. **A fallback CI job runs the untagged suite under `mockito-subclass`.** If it stays green, the project retains the option to run in a restricted environment; if it breaks, you learn on the day it breaks, not on the day you need it. 4. **Code review treats a new instrumentation-only test as a design question**: is there a seam we could introduce instead? Answering "no, and here is why" is fine; not asking is not. 5. **Adapters own the coupling.** Where a final vendor type must be used, keep it inside one adapter class, test that adapter against the real thing or a contract test, and let the rest of the codebase depend on your interface — which mocks trivially under any maker. ## What to avoid - **Spreading instrumentation dependence by default.** Once `mockStatic` becomes routine, hundreds of tests quietly acquire the requirement, and the migration cost when the platform changes is enormous. - **Two makers configured inconsistently across modules.** Competing `org.mockito.plugins.MockMaker` resources make the effective behaviour classpath-order dependent. Decide once, per repository. - **Suppressing the JDK agent warning and forgetting it.** `-XX:+EnableDynamicAgentLoading` hides a forward-compatibility signal; it is fine as a stopgap, bad as a permanent state. - **Refusing the inline maker on principle.** Testing legacy code that you cannot restructure is a legitimate use, and the subclass maker's silent failure mode on final methods (the stubbing simply does not apply) is worse than instrumenting. ## How to present it Name the capability boundary precisely — final types, statics, constructors — say which environments lack it, and describe the containment strategy: default on, tagged minority, verified fallback, design pressure applied at review. Then acknowledge the counterweight: the goal is not purity but the ability to change platform without rewriting the suite, and a small, well-justified set of instrumented tests is a perfectly healthy outcome.
- What concrete refactorings remove the need for instrumentation-only mocking?Wrap a final third-party client in a thin interface you own and mock that; inject a java.time.Clock instead of calling a static now(); pass a factory or supplier instead of calling new inside the method; and extract the vendor interaction into a single adapter that is covered by a contract or integration test. Each replaces an instrumentation dependency with an ordinary seam that any mock maker handles. The refactoring also reduces coupling to the vendor API, which pays off beyond testing.
- Why keep a CI job that runs the suite under the subclass mock maker?It continuously proves that the fallback path still works, so the project keeps the option of running in an environment without instrumentation. Without it, the dependency grows silently and is only discovered under time pressure. The job is cheap because it runs the same tests with a different dependency and an exclusion filter.
- Is it ever right to make the subclass maker the project default?Yes, when the target platform cannot instrument at all — Android unit tests being the classic case — or when a security policy forbids agents. You then accept that final classes and methods are not mockable and design around it, which many teams consider a feature. The important part is making the choice explicitly and once, rather than letting classpath ordering decide.
saying these in an interview costs you the question
- Treating mocking final third-party types as free rather than as coupling
- Assuming every JVM will always permit dynamic agent attachment
- Configuring different mock makers ad hoc across modules
- Rejecting the inline maker outright even for legacy code that cannot be restructured
- Having no way to tell which tests depend on instrumentation