spring 集成测试并非跨进程通信，而是与被测应用共享同一 jvm 进程；测试框架（如 junit）通过 spring test 模块提供的扩展机制，在启动时构建并管理独立的测试专用 applicationcontext，从而支持 @mockbean 动态替换、@autowired 自动注入等能力。
spring 集成测试并非跨进程通信，而是与被测应用共享同一 jvm 进程；测试框架（如 junit）通过 spring test 模块提供的扩展机制，在启动时构建并管理独立的测试专用 applicationcontext，从而支持 @mockbean 动态替换、@autowired 自动注入等能力。
在 Spring 集成测试中，一个常见误解是：测试运行于“另一个进程”，而应用上下文（ApplicationContext）驻留在 Tomcat 或其他容器进程中——因此无法被测试直接操作。事实恰恰相反：Spring 集成测试默认不依赖外部容器进程，而是在测试 JVM 内部完整启动一个轻量级、可定制的 ApplicationContext。
该上下文由 Spring Test 框架（如 spring-test 模块）驱动，通过 JUnit 的生命周期扩展（如 JUnit 5 的 SpringExtension）自动触发。当你使用 @SpringBootTest、@ContextConfiguration 或 @WebMvcTest 等注解时，Spring Test 并非连接远程服务，而是：
- 在同一 JVM 中初始化嵌入式环境（例如嵌入式 Tomcat、Netty 或纯 Servlet 容器）；
- 解析配置类/组件扫描路径，构建独立的 ApplicationContext 实例；
- 将该上下文绑定到当前测试线程（通过 ContextCache 和 TestContextManager 管理复用）；
- 在测试执行前完成 Bean 创建、依赖注入、AOP 代理等全部 Spring 容器行为。
因此，@Autowired 能成功注入，是因为 Spring Test 在测试方法执行前已将目标 Bean 注入到测试实例字段中；而 @MockBean 的本质是：在上下文刷新（refresh()）前，动态注册一个 Mockito 创建的 Mock Bean，并移除或覆盖同类型的现有 Bean —— 全部发生在同一个 ApplicationContext 生命周期内，无需跨进程通信。
@SpringBootTest
class UserServiceIntegrationTest {
@Autowired
private UserService userService; // 注入的是测试上下文中的真实 Bean
@MockBean
private UserRepository userRepository; // 替换上下文中原有的 UserRepository 实例
@Test
void shouldReturnUserWhenIdExists() {
// given
when(userRepository.findById(1L)).thenReturn(Optional.of(new User("Alice")));
// when
User result = userService.findById(1L);
// then
assertThat(result.getName()).isEqualTo("Alice");
}
}
⚠️ 注意事项：
- @MockBean 作用于整个测试类的 ApplicationContext，若需方法级隔离，可配合 @DirtiesContext 或使用 @TestConfiguration + @Bean 手动注册；
- 多个 @SpringBootTest 类可能复用缓存的上下文（默认按配置哈希缓存），避免重复启动开销，但也意味着 @MockBean 的副作用可能影响后续测试——建议合理使用 @DirtiesContext 控制生命周期；
- 若需真正模拟“外部进程”场景（如调用远程 HTTP 服务），应使用 @RestClientTest 或 MockRestServiceServer，而非误用 @MockBean 模拟客户端。
简言之，Spring 集成测试的强大，源于其对测试生命周期与容器生命周期的深度整合——它不是“访问另一个进程的上下文”，而是“在测试进程中精准重建并可控操纵专属上下文”。理解这一点，是掌握 Spring 测试体系设计哲学的关键起点。
