@Mock / @InjectMocks

## The problem these solve A **unit test** checks one class (the *system under test*, or SUT) in isolation. But classes rarely stand alone — a `UserService` calls a `UserRepository`, a `PasswordEncoder`, etc. These are its **collaborators** (dependencies). In a unit test you do not want to hit a real database or send real emails. You replace each collaborator with a **mock**: a fake object that implements the same type but whose behaviour you control. **Mockito** is the dominant Java mocking library. It lets you create mocks and tell them how to behave ("stubbing") and verify how they were called. ## @Mock `@Mock` is a field annotation that asks Mockito to create a mock of that field's type: ```java @Mock UserRepository repository; ``` This is equivalent to `repository = Mockito.mock(UserRepository.class)`. A fresh mock does nothing useful yet: every method returns a **default value** — `null` for objects, `0` for numbers, `false` for booleans, an empty collection for collection types. You then **stub** the methods you care about with `when(repository.findById(1L)).thenReturn(user)`. ## @InjectMocks `@InjectMocks` goes on the field holding the **real** object you want to test: ```java @InjectMocks UserService service; ``` Mockito will (a) instantiate `UserService` and (b) inject the other `@Mock`/`@Spy` fields in the same test class into it. So the real `UserService` runs, but its dependencies are your controllable mocks. Note: `@InjectMocks` creates a **real** instance, not a mock — only its dependencies are mocked. ## How injection is resolved (the order) Mockito tries three strategies, in this order: 1. **Constructor injection** — if the class has a constructor, Mockito picks the constructor with the most arguments it can satisfy and passes mocks in. (This is the preferred, modern style and works with `final` fields.) 2. **Property (setter) injection** — for any remaining unset dependencies, it calls matching setters. 3. **Field injection** — it writes directly into fields (even private ones, via reflection). Within each strategy, mocks are matched **by type**; if several mocks share a type, Mockito disambiguates **by field name**. Unmatched dependencies are simply left null — Mockito does **not** fail the test for them, which is a common source of surprise `NullPointerException`s. ## Turning the annotations on Annotations are inert until something processes them. Three options: - **JUnit 5:** annotate the test class with `@ExtendWith(MockitoExtension.class)`. This is the recommended modern approach; it also enforces *strict stubbing* (it fails the test if you stub something that is never used). - **Manual:** call `MockitoAnnotations.openMocks(this)` in an `@BeforeEach` method (it returns an `AutoCloseable` you can close in `@AfterEach`). The older `initMocks(this)` is deprecated in favour of `openMocks`. - **JUnit 4:** `@RunWith(MockitoJUnitRunner.class)` or the `MockitoRule`. Without one of these, the fields stay `null`. ## A complete example ```java @ExtendWith(MockitoExtension.class) class UserServiceTest { @Mock UserRepository repository; @InjectMocks UserService service; @Test void returnsUserName() { when(repository.findById(1L)).thenReturn(new User(1L, "Ada")); assertEquals("Ada", service.nameOf(1L)); verify(repository).findById(1L); } } ``` ## Key caveats - `@InjectMocks` silently leaves a dependency null if no matching mock exists — you then get an NPE deep in the SUT, not a clear error. - Mixing constructor and field injection on the same class can produce a *partially* wired object if a constructor exists but cannot be fully satisfied. - Many teams now prefer **plain constructor calls** (`new UserService(repository)`) over `@InjectMocks` because it is explicit and fails loudly when a dependency is missing.