SpringBoot 2测试报错：Mockito插件初始化失败求助

Hey there, let's break down this warning you're hitting when running your Spring Boot 2 controller tests. That message from TestContextManager about a failure in the afterTestMethod callback of ResetMocksTestExecutionListener usually pops up when Spring tries to reset your mock objects after a test finishes, but hits a snag along the way. It's a warning (not an error), so your tests might still pass, but it's definitely worth fixing to keep your test suite clean.

Here are the most common causes and fixes:

1. Mismatched Mock Annotations or Missing Extensions #

If you're mixing up Mockito's native annotations with Spring Boot's test annotations, you might trigger lifecycle conflicts:

• For integration tests (using @SpringBootTest): Stick with @MockBean (from org.springframework.boot.test.mock.mockito) to inject mocks into the Spring context, not plain Mockito @Mock.
• For unit tests (not loading the full Spring context): Use @ExtendWith(MockitoExtension.class) (or SpringExtension.class for Spring-aware unit tests) alongside @Mock to ensure proper mock initialization and resetting.

Example of a correct unit test setup:

@ExtendWith(MockitoExtension.class)
class DemoControllerTest {
    @Mock
    private SomeService service;
    
    @InjectMocks
    private DemoController controller;
    
    // Test methods here
}

2. Trying to Mock Final Classes/Methods #

Mockito can't mock final classes or methods out of the box, and the reset listener will fail when it tries to reset these mocks. To fix this:
Add the Mockito Inline dependency to your build file, which enables mocking of final types.

For Maven:

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-inline</artifactId>
    <scope>test</scope>
    <!-- Use a version compatible with your Spring Boot version; Spring Boot BOM usually manages this -->
</dependency>

For Gradle:

testImplementation 'org.mockito:mockito-inline'

3. Conflicts with Custom TestExecutionListeners #

If you've added custom TestExecutionListener implementations to your test class, they might interfere with the ResetMocksTestExecutionListener's execution order or logic:

• Check if your test class uses @TestExecutionListeners to override default listeners. If so, ensure ResetMocksTestExecutionListener is included and ordered correctly (usually after your custom listeners).
• As a quick test, temporarily remove any custom listeners to see if the warning disappears. If it does, adjust your listener's logic to avoid conflicts.

4. Unconventional Mock Manipulations #

If your test methods modify mock objects in non-standard ways (like manual state changes or using spies without proper resetting), the auto-reset mechanism might fail:

• Instead of manually altering mock states, rely on Mockito's stubbing methods (when().thenReturn()) for predictable behavior.
• If you must use spies, explicitly reset them in an @AfterEach method:

  @AfterEach
  void tearDown() {
      Mockito.reset(spiedObject);
  }
  

Bonus: Debug the Exact Mock Causing the Issue #

To pinpoint which mock is triggering the warning, enable Mockito's strict mode in your test setup. This will throw a more detailed error instead of just a warning:

@BeforeEach
void setUp() {
    Mockito.mockitoSession()
           .initMocks(this)
           .strictness(Strictness.STRICT_STUBS)
           .startMocking();
}

内容的提问来源于stack exchange，提问作者Régis Le Coz