A team keeps adding Mockito constructor-interception scopes to unit-test classes that instantiate their collaborators with `new` internally. How would you decide between keeping that approach and refactoring the code to inject the collaborator instead?

## Two ways to break a hard-coded dependency When a class does `new Collaborator(...)` inside a method, a unit test has two routes to control that collaborator. **Interception.** `Mockito.mockConstruction(Collaborator.class)` instruments the class so that, inside a thread-local scope, construction yields a mock. Nothing about the production class changes. **Inversion.** Change the production class so the collaborator arrives from outside: a constructor parameter for a long-lived dependency, or an injected factory/supplier when a fresh instance is genuinely needed per operation. The test then passes a mock directly. ## What inversion buys - **Honest API.** The dependency appears in the constructor signature, so readers and DI containers see it. Hidden `new` calls make a class look cheaper than it is. - **No instrumentation.** No inline mock maker, no Java agent warnings, no interaction with coverage or bytecode tooling, faster tests. - **Robust tests.** The test refers to a type it is given, not to a construction site buried in a method body. Refactoring the production method does not silently disarm the mock. - **Reuse.** The same seam serves other needs — alternate implementations, decorators, retries, per-tenant configuration. - **Real constructor coverage.** Interception skips the constructor body, so validation and initialisation logic there is never exercised in those tests. ## What interception buys - **Zero production change.** Critical for third-party classes, generated code, and code under a change freeze. - **No API churn.** Adding a parameter to a widely used constructor can ripple through hundreds of call sites; interception avoids the ripple while you are still learning the code. - **Neutralising dangerous constructors.** If the constructor opens sockets, spawns threads, reads files or blocks, skipping its body is exactly what a unit test wants. - **A safety net for the refactor itself.** Legacy-code practice is to write characterisation tests first, using whatever seam you can get, then refactor under their protection and simplify the tests afterwards. Interception is an excellent temporary seam for that. ## The costs to name out loud Interception is *global within its scope for that type on that thread*: every construction of the type is affected, including ones you did not intend, such as a helper the test framework itself builds. It is thread-local, so async production code slips through. A leaked scope corrupts unrelated tests. And it encodes an implementation detail as a test expectation, which is the classic mechanism by which a suite becomes resistant to refactoring — the tests break when the code changes shape, not when the behaviour changes. ## A decision rule 1. Do we own and can we deploy the class? If yes, prefer inversion; the refactor is usually smaller than the argument about it. 2. Is a fresh instance genuinely needed per call? Inject a factory or `Supplier`, not the instance. 3. Is the class third-party or frozen? Interception, or wrap it behind a thin adapter interface we own and mock the adapter — often the better long-term move, because the adapter also isolates us from the library's API. 4. Is the constructor itself dangerous in tests? Interception is fine even for our own code, but consider whether that constructor should be doing work at all. 5. Are we about to refactor? Use interception as scaffolding, then delete it once the seam exists. ## Organisational angle If constructor interception appears in dozens of test classes, that is a metric, not a style choice: it says the codebase's units create their own dependencies, which also blocks reuse, complicates lifecycle management, and pushes teams toward heavy integration tests. I would track its usage, allow it explicitly at boundaries with third-party libraries, and treat new occurrences in core domain code as review findings with the refactor as the expected fix.