MVC控制器测试MockBean未注入问题及JUnit注解替换生效原因咨询

我来帮你拆解这个问题背后的原因，核心还是JUnit版本兼容和Spring测试上下文初始化的细节问题：

先明确两者的本质关系 #

首先澄清一个基础概念：SpringRunner其实就是JUnit4版本的SpringExtension，它的源码直接继承了SpringJUnit4ClassRunner，专门用来适配Spring测试上下文；而@ExtendWith(SpringExtension.class)是JUnit5官方指定的集成Spring测试的标准注解，理论上两者功能完全等价——那为什么会出现你遇到的差异？

问题的核心触发场景 #

你的情况大概率是以下某一种原因导致的：

1. 依赖版本不兼容或缺失
   如果你的Spring Boot版本比较旧（比如2.1.x及以前），它对JUnit5的支持并不完善，默认的spring-boot-starter-test依赖里可能没有完整引入JUnit5的核心组件（比如junit-jupiter-api、junit-jupiter-engine）。这种情况下，@ExtendWith(SpringExtension.class)无法正常触发Spring测试上下文的初始化流程，自然就没法创建@MockBean实例，最终导致调用Mockito.when()时传入null，抛出异常。
   而@RunWith(SpringRunner.class)是Spring Boot对JUnit4的稳定支持方案，旧版本的starter-test里默认包含JUnit4依赖，所以能顺利完成MockBean的初始化。

2. JUnit API混用
   检查你的测试类里的@Test注解：如果用的是JUnit4的org.junit.Test，同时搭配了JUnit5的@ExtendWith(SpringExtension.class)，这会导致测试运行机制混乱——SpringExtension是为JUnit5的生命周期设计的，无法正确识别JUnit4的@Test注解，进而跳过了MockBean的初始化步骤。
   换成@RunWith(SpringRunner.class)后，它会按照JUnit4的生命周期处理测试，自然能正确初始化MockBean。

3. 测试上下文初始化的细微差异
   JUnit5的测试生命周期和JUnit4存在一些细节区别，比如扩展加载顺序、上下文缓存机制等。如果你的测试类里有自定义扩展或者特殊配置，可能在JUnit5下触发了上下文初始化的异常，而JUnit4的SpringRunner则能兼容这种配置。

验证和修复建议（继续使用JUnit5的方案） #

如果你想坚持用JUnit5的标准配置，可以按以下步骤排查：

• 检查pom.xml或build.gradle，确保引入完整的JUnit5依赖，同时排除JUnit4避免冲突：

  <!-- Maven示例 -->
  <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-test</artifactId>
      <scope>test</scope>
      <exclusions>
          <exclusion>
              <groupId>junit</groupId>
              <artifactId>junit</artifactId>
          </exclusion>
      </exclusions>
  </dependency>
  <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter-api</artifactId>
      <scope>test</scope>
  </dependency>
  <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter-engine</artifactId>
      <scope>test</scope>
  </dependency>
  

• 替换测试类中的@Test注解为JUnit5的org.junit.jupiter.api.Test
• 确保@WebMvcTest指定了目标控制器类，比如：@WebMvcTest(AddressesController.class)

总结 #

你换成@RunWith(SpringRunner.class)生效，本质是因为你的测试环境更适配JUnit4的运行机制，而JUnit5的配置存在依赖缺失或API混用的问题。建议优先排查依赖和测试注解的一致性，逐步迁移到JUnit5的标准配置上，毕竟JUnit5是Java测试的未来主流。

内容的提问来源于stack exchange，提问作者xmen-5