This is an issue when a test class field is initialized using a manual mock creation method while the class is annotated with a testing framework extension that automatically initializes mocks.

In Java with Mockito, this specifically occurs when using the mock() method for field initialization in a class annotated with @ExtendWith(MockitoExtension.class) (JUnit 5) or @RunWith(MockitoJUnitRunner.class) (JUnit 4).

Why is this an issue?

When you use the testing framework’s test runner or extension, it automatically processes mock annotations in your test class. This means you can declare mocks using annotations instead of manually calling the mock creation function.

Using mock annotations has several advantages:

• Cleaner code: The annotation approach is more declarative and easier to read. It clearly shows which fields are mocks at a glance.
• Idiomatic practice: Mock annotations are the standard way to declare mocks when using the testing framework’s runner or extension.
• Strict stubbing enabled: Most importantly, annotation-based mocks benefit from strict stubbing, which is enabled by default with the framework’s test runner or extension.

Strict stubbing is a valuable feature that helps maintain test quality:

• It fails your test if you stub a method but never call it during the test. This detects dead code in your tests - stubs that were set up but are no longer needed.
• It fails your test if you configure unnecessary stubbing. This keeps your tests focused and prevents outdated setup code from accumulating.
• It catches common mistakes, like stubbing the wrong method or setting up behavior that your test doesn’t actually verify.

The mock creation function is still appropriate for creating ad-hoc mocks inside test method bodies, where you need a mock for just one specific test case. But for field-level mocks that multiple tests might use, annotations are the better choice.

What is the potential impact?

Using programmatic mock creation methods for field initialization instead of declarative mock annotations makes tests harder to maintain and can hide quality issues. Without automatic validation of mock usage, unnecessary or unused mocks can accumulate over time, making tests slower to understand and update. The test suite becomes less reliable at catching setup mistakes or outdated test code.

How to fix it in JUnit 4

For JUnit 4 tests using MockitoJUnitRunner, replace the field initialization with the @Mock annotation.

Code examples

Noncompliant code example

@RunWith(MockitoJUnitRunner.class)
public class OrderProcessorTest {
  private final PaymentService paymentService = mock(PaymentService.class); // Noncompliant
  private final NotificationService notificationService = mock(NotificationService.class); // Noncompliant

  @Test
  public void testProcessOrder() {
    // test logic...
  }
}

Compliant solution

@RunWith(MockitoJUnitRunner.class)
public class OrderProcessorTest {
  @Mock
  private PaymentService paymentService;

  @Mock
  private NotificationService notificationService;

  @Test
  public void testProcessOrder() {
    // test logic...
  }
}

How to fix it in JUnit 5

For JUnit 5 tests using MockitoExtension, replace the field initialization with the @Mock annotation. Note that ad-hoc mocks created inside test methods can still use mock() - this rule only applies to field declarations.

Code examples

Noncompliant code example

@ExtendWith(MockitoExtension.class)
class DataProcessorTest {
  private final DataSource dataSource = mock(DataSource.class); // Noncompliant

  @Test
  void testProcessData() {
    // This ad-hoc mock inside a method is fine
    DataValidator validator = mock(DataValidator.class);

    when(dataSource.getData()).thenReturn(someData);
    // test logic...
  }
}

Compliant solution

@ExtendWith(MockitoExtension.class)
class DataProcessorTest {
  @Mock
  private DataSource dataSource;

  @Test
  void testProcessData() {
    // This ad-hoc mock inside a method is fine
    DataValidator validator = mock(DataValidator.class);

    when(dataSource.getData()).thenReturn(someData);
    // test logic...
  }
}

Resources

Documentation

• Mockito Documentation - @Mock Annotation
• Mockito Documentation - MockitoExtension (JUnit 5)
• Mockito Documentation - MockitoJUnitRunner (JUnit 4)
• Baeldung - Mockito Strict Stubbing and the UnnecessaryStubbingException