Some teams forbid Mockito's @InjectMocks and require the object under test to be constructed by hand in every test. What is the argument on each side, and how would you decide the rule for a large codebase?

## Framing the decision This is not a question about which API is nicer. It is a question about **where you want a wiring mistake to be detected**: at compile time, at test time, or in production. `@InjectMocks` and manual construction sit at different points on that axis, and a large codebase should choose deliberately rather than by habit. ## The case for @InjectMocks **Boilerplate reduction at scale.** A class with six dependencies produces a six-argument `new` in every test class that touches it. If eight test classes exist, adding a seventh dependency is eight edits. With `@InjectMocks` plus a new `@Mock` field, it is often zero edits in classes that do not care about the new collaborator. **Uniformity.** Everyone recognises the shape: mocks above, object under test below. New joiners copy it without thinking, and reviewers do not have to read wiring code. **It tolerates awkward hierarchies.** Deep inheritance, package-private constructors, setter-injected legacy classes — the annotation copes with all of them without the test having to know which route the dependency takes. ## The case against **It fails open.** Mockito explicitly does not report an injection failure. An unresolved constructor argument is passed as `null`; a dependency that is not reachable by the winning strategy stays `null`. The symptom is an NPE thrown from production code in whichever test happens to exercise that path — and if no test exercises it, no symptom at all, which is worse. **Compilation stops protecting you.** With manual construction, adding a constructor parameter breaks every test that builds the object. That is not friction; that is the compiler telling you which tests now need a decision about the new collaborator. `@InjectMocks` removes that signal, and the exact same property is what its advocates list as a benefit. Whether it is a benefit depends on whether you consider "tests keep compiling" a good outcome when the object's contract changed. **Behaviour depends on class shape.** Which of constructor/setter/field injection runs is decided at runtime by the class's structure, and the chain stops at the first success. A reader of the test cannot tell what was injected without reading the production class. Same-type dependencies fall back to a field-name heuristic; constructor arguments are matched by type alone. **It hides design pressure.** A constructor with nine parameters is painful to write in a test — and that pain is information. Automating it away removes the main feedback loop that keeps classes from accumulating dependencies. ## How I would decide **Start from the failure mode you can afford.** In a codebase where tests are the main safety net and constructors change often, silent nulls are expensive: the test suite goes green while coverage of the new dependency is zero. That argues for manual construction as the default. **Measure the actual cost.** "Too much boilerplate" is usually one `@BeforeEach` with one `new`. If the objection is really about a fifteen-argument constructor, the honest fix is to split the class, or introduce a small test data builder/factory shared across test classes — which gives you the boilerplate reduction *and* compile-time checking. **Segment the codebase.** A blanket ban is rarely worth the migration cost. A workable policy: - New code: construct explicitly. Enforce in review, not with a custom lint rule you will have to maintain. - Legacy classes with wide or setter-based wiring: `@InjectMocks` allowed, no rewrite required. - Any class where two dependencies share a type: explicit construction, no exceptions — the name heuristic is not something to bet on. **Add the cheap safety net either way.** If the annotation stays, a shared assertion in the base test class (or a small helper that reflects over the object under test and fails on any null dependency) restores the loud failure at near-zero cost. Most teams never bother, which is exactly why the null shows up in production paths instead. **Do not let this become a religious rule.** The cost difference per test is small; the cost difference at the moment a constructor changes is not. Argue the policy in those terms, decide once, write it down in the testing conventions, and stop relitigating it in code review. ## What a strong answer sounds like A principal-level answer does not simply pick a side. It names the tradeoff (silent runtime null vs. one line of typing), identifies the second-order effects (loss of compile-time feedback, suppressed design pressure, hidden strategy selection), proposes a segmented policy rather than a blanket ban, and mentions a mitigation for whichever side the team lands on.