Annotation Initialization

## Why the field is null `@Mock` is a plain annotation retained at runtime. Declaring it changes nothing about the field: at construction time the JVM initializes it to `null` like any uninitialized reference. Something must *process* the annotation — walk the test instance's declared fields (including inherited ones), see the annotation, call `Mockito.mock(...)` with the field's type and name, and assign the result by reflection. Mockito ships three processors, and you pick exactly one. ## Option 1 — the JUnit 5 extension ```java @ExtendWith(MockitoExtension.class) class CheckoutServiceTest { @Mock OrderRepository repository; } ``` It lives in the separate `mockito-junit-jupiter` artifact (test scope), so a missing dependency shows up as an unresolvable `MockitoExtension`. The extension initializes annotated fields before each test method, tears down afterwards, applies strict stubs by default, and can also resolve `@Mock`-annotated **parameters** of test and lifecycle methods — handy for a mock only one test needs. ## Option 2 — openMocks, called explicitly ```java class CheckoutServiceTest { @Mock OrderRepository repository; private AutoCloseable mocks; @BeforeEach void init() { mocks = MockitoAnnotations.openMocks(this); } @AfterEach void tearDown() throws Exception { mocks.close(); } } ``` This is framework-agnostic — JUnit 4, JUnit 5, TestNG, or a plain `main`. It is the escape hatch when you cannot register the extension, for example inside a test infrastructure base class shared across frameworks. `openMocks` replaced the older `initMocks(this)`, which is deprecated because it did not give you the closeable handle. ## Option 3 — the JUnit 4 runner or rule `@RunWith(MockitoJUnitRunner.class)` initializes annotations and validates Mockito usage after each test. `@Rule public MockitoRule rule = MockitoJUnit.rule();` does the same while leaving the runner slot free for another runner (a parameterized runner, a Spring runner). Both are JUnit 4 only. ## The failure modes that produce null fields 1. **No initializer at all.** The most common by far, especially when a test class is created by copying one that had the extension and dropping the annotation. 2. **A JUnit 4 runner on a JUnit 5 test.** JUnit Jupiter does not understand `@RunWith`; it neither honours it nor complains, so the class runs with uninitialized mocks. The same happens with a JUnit 4 `@Rule` field under Jupiter. 3. **Mixed imports.** `@BeforeEach` from Jupiter combined with `org.junit.Test` (JUnit 4), or vice versa: the setup method belongs to a lifecycle the executing engine ignores, so `openMocks` never runs. Symptom: mocks are null even though the setup method visibly exists. 4. **The initializer runs too late or not for this instance.** Calling `openMocks(this)` from a helper that receives a different object, or initializing in `@BeforeAll` (static, wrong instance), leaves the per-test fields null. 5. **The annotation is not Mockito's.** Importing a different framework's `@Mock` — or Spring's bean-replacing mock annotation, which requires a Spring test context rather than the Mockito extension — is a quiet copy-paste trap. 6. **The field is static, or the class is executed by an engine that constructs test instances differently.** Mockito's processors assign instance fields on the test instance they are handed. ## Diagnosing quickly Ask in order: Is there exactly one initializer? Does the executing engine match it (Jupiter extension vs JUnit 4 runner/rule)? Are all lifecycle and test annotations from the same JUnit generation? Is `mockito-junit-jupiter` on the test classpath? Is the setup method non-static and non-private? That checklist covers essentially every occurrence. ## Do not stack initializers Registering the extension *and* calling `openMocks` in `@BeforeEach` is redundant: fields are created twice, the second set replacing the first, and any stubbing done between the two is lost. It also confuses session validation. Pick one mechanism per class and let base classes declare it rather than each subclass repeating it. ## A note on the alternative You can always avoid the question entirely by creating collaborators with `Mockito.mock(...)` and wiring the class under test through its constructor. That needs no initializer at all, and some teams prefer it for exactly that reason. The annotation route buys concision and mock naming; the manual route buys explicitness. ## Interview framing Say it in one sentence — the annotation is inert until an initializer processes it — then name the three initializers and the two classic traps (JUnit 4 runner under Jupiter, mixed imports). That is the complete answer.