In Mockito, what does the @InjectMocks annotation do to the field it is placed on, and where does it get the values it injects?

## The problem it solves A typical unit test has one class you actually want to exercise and several collaborators you want to fake. Written by hand, the setup looks like this: create a mock repository, create a mock mailer, then `new OrderService(repository, mailer)`. `@InjectMocks` automates the third line. You declare the collaborators as `@Mock` fields, annotate the field holding the class under test with `@InjectMocks`, and Mockito builds the object and hands it the mocks. ## What the annotated field actually holds The `@InjectMocks` field holds a **real instance** of its declared type. Mockito does not proxy it, does not intercept its methods, and does not record calls on it. When your test calls `service.placeOrder(...)`, the genuine production code runs. That is deliberate: the class under test must be real, or the test asserts nothing about your code. Only the things it talks to are replaced. Because it is real, you cannot `verify(...)` calls on it or stub its methods — attempting to do so throws `NotAMockException`. If you truly need to stub one of its own methods you have to make it a spy instead, which is a different (and much more contentious) technique. ## Where the injected values come from Mockito scans the **test class instance**, including inherited fields from superclasses, for fields annotated `@Mock` or `@Spy`. Those become the pool of injection candidates. Anything else in the test class — a plain `new Clock()` field, a constant, a value you assigned in `@BeforeEach` — is invisible to the mechanism. This surprises people: if a dependency has no `@Mock` field of the right type, Mockito leaves it as `null` rather than complaining. Matching is by **type** first. When exactly one candidate matches a dependency's type, it is used. When several mocks share a type (two `DataSource` mocks, say), Mockito falls back to matching the **field name** of the mock against the name of the target field or setter, which is why naming your mocks after the fields they replace is more than cosmetic. ## How the value gets in Mockito tries, in order: pass the mocks as **constructor arguments**; call **setters** whose parameter type matches a mock; write directly to the **fields** by reflection. It uses the first strategy that succeeds — it does not combine them. The important consequence for a beginner is that you do not need setters or public fields: a class with a normal constructor is wired through that constructor, which is also the design most teams want. ## It does nothing on its own The annotations are inert metadata. Something must process them: - JUnit 5: `@ExtendWith(MockitoExtension.class)` on the test class. - Any framework, manually: `MockitoAnnotations.openMocks(this)` in a `@BeforeEach`, ideally closing the returned `AutoCloseable`. - JUnit 4: `@RunWith(MockitoJUnitRunner.class)` or `MockitoRule`. Without one of these, every annotated field is `null` and the first line of your test throws a `NullPointerException`. This is the single most common "my Mockito test doesn't work" cause. ## Lifecycle JUnit creates a new test-class instance per test method, and annotation processing runs per test method too. So both the mocks and the `@InjectMocks` object are recreated for every test — stubs, recorded interactions and any state mutated inside the object under test do not bleed into the next test. That isolation is free, and you should not fight it by making the fields `static`. ## A worked shape ```java @ExtendWith(MockitoExtension.class) class OrderServiceTest { @Mock OrderRepository repository; // fake collaborator @Mock Mailer mailer; // fake collaborator @InjectMocks OrderService service; // REAL object under test } ``` Inside a test, you stub `repository`, call `service.placeOrder(...)` for real, and `verify(mailer)` afterwards. The mental model is a triangle: stub the inputs, run the real thing, verify the outputs. ## When it is not worth it For a class with one or two dependencies, `new OrderService(repository, mailer)` in a `@BeforeEach` is just as short, fails loudly when the constructor changes, and is obvious to a reader. `@InjectMocks` earns its keep on wider constructors and in suites where that pattern is already established — but it is a convenience, not a requirement, and it hides wiring errors rather than reporting them.