Spring测试这块我一直觉得是被低估的宝藏。标题里两个关键词——JUnit 5集成与测试切片技术——前者解决“测试怎么写、怎么跑”的问题后者解决“测试跑得慢、依赖重”的问题。很多团队项目跑一遍全量测试要十几分钟一大半时间都耗在等测试上改成切片测试之后单个模块的测试基本秒级完成。这篇文章想把这两条线串起来讲透适合正在做Spring Boot项目、想提升测试效率的开发者或者刚接触Spring测试想系统梳理的人。1. 先说为什么Spring官方把测试当成一等公民1.1 从依赖坐标看Spring对JUnit 5的支持思路新建Spring Boot项目时spring-boot-starter-test是我每次都会第一时间加进去的依赖。这个starter打包了JUnit 5、AssertJ、Mockito、JSONAssert、Spring Test等一整套测试基础设施。注意这里的JUnit 5指的是JUnit Jupiter默认情况下不需要再单独引junit-jupiter-api因为starter里已经通过传递依赖带进来了。依赖版本这件事值得留意。Spring Boot 2.2开始默认支持JUnit 5如果你维护的是老版本Spring Boot 2.1或更早默认用的还是JUnit 4需要先排除JUnit 4的starter再显式引入Jupiter的启动器。很多人升级依赖后发现测试跑不起来大部分情况下就是新旧两套测试框架同时在classpath里打架。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency装上这个依赖之后测试代码里就能直接用Test、断言、Mockito等能力。但有一个问题Spring本身是个容器框架JUnit 5运行测试时并不知道Spring容器的存在。要让两者协同工作需要中间桥梁这就是下面要说的SpringExtension。1.2 SpringExtension才是JUnit 5集成中的关键角色JUnit 5本身不关心Spring。它有一套扩展机制ExtendWith就是入口。SpringExtension是Spring测试框架对JUnit Jupiter扩展机制的具体实现它告诉JUnit你要在跑测试的时候去启动Spring上下文并把上下文里的Bean注入到测试实例中。有了这个扩展Autowired才能在测试类里生效Transactional测试回滚、DirtiesContext这些注解也才能被解析。很多人只看到SpringBootTest以为它是启动Spring的唯一入口其实SpringBootTest只是个组合注解内部通过ExtendWith(SpringExtension.class)把这个扩展挂上去。真正干活的机制是Spring的TestContext框架。TestContext框架有几个值得注意的点第一上下文缓存。同一个测试配置的上下文在整个测试执行期间会被缓存复用不会每个测试方法都重启一遍容器这是切片测试能做得快的基础。第二依赖注入的入口是TestContextManager它负责在每个测试方法前后触发回调比如事务回滚就是通过回调实现的。第三MockBean的替换逻辑也是挂在TestContext框架下的而不是Mockito本身的行为。理解这层关系很多诡异的问题就能想通了。有一次我在测试类里直接写了MockBean但注入的Mock完全不生效排查半天发现是测试类没有被SpringExtension管理也就是说测试类上没有SpringBootTest或其他能激活扩展的注解。这类问题本质上就是没搞清“谁在管理测试的生命周期”。2. 测试切片到底是什么从全量上下文到局部上下文2.1 切片测试的设计逻辑SpringBootTest默认启动完整的ApplicationContext会把项目里所有的Bean都加载进来。对于端到端集成测试来说这很有必要但如果你只是想测Controller的MVC逻辑或者Repository的数据访问逻辑把整个容器加载起来就显得过重了。打个比方你想验证一家餐厅的招牌菜好不好吃直接把整个后厨、采购、财务系统全跑一遍虽然也能得出结论但效率和成本都很离谱。切片测试的思路更像“只看某个档口”只准备这道菜需要的锅、食材和厨师其他东西一律不碰。Spring Boot提供了一组切片注解最常用的包括WebMvcTest、DataJpaTest、JsonTest、RestClientTest等。这些注解会把上下文裁剪到最小集合只加载当前测试关注的Bean和对应的自动配置。以WebMvcTest为例它只加载Spring MVC相关的自动配置包括Controller、Filter、ControllerAdvice、Jackson配置等但不会加载Service、Repository这些下层Bean。同时它还会自动配置MockMvc方便你直接发请求验证接口行为。这个“只加载相关切片”的设计核心收益是单个测试类的启动时间从秒级降到毫秒级同时被测类的依赖隔离更彻底出问题更容易定位。2.2 常用切片注解能覆盖哪些场景我整理了Spring Boot提供的主要切片注解按场景列出来方便对照。切片注解主要覆盖范围典型使用场景WebMvcTestMVC控制器、过滤器、参数解析、消息转换器测接口参数绑定、返回JSON结构、状态码DataJpaTestJPA仓库、实体映射、数据源自动配置测Repository方法、SQL语句正确性JsonTestJSON序列化与反序列化测DTO在不同格式下的映射结果RestClientTestRestTemplate或WebClient的自动配置测REST客户端请求构造与响应解析DataRedisTestRedis相关Bean与序列化配置测RedisTemplate操作与数据映射使用切片注解有一个隐含约定只有被切片自动配置覆盖的Bean才会被加载。比如在WebMvcTest里直接Autowired一个Service就会报错因为Service不在这个切片的扫描范围。这时候要么用MockBean模拟掉要么把需要的配置类通过Import加进来。很多新手在这里卡住以为SpringBootTest能用切片就一定也能用实际上两者对Bean集合的预期截然不同。3. 实操把JUnit 5和测试切片落到真实项目里3.1 最小依赖清单与初始化配置假设项目基于Spring Boot 2.2以上版本最小依赖只需要一个dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency如果想验证Spring容器能不能正常启动最通用的组合是SpringBootTest加AutoConfigureMockMvc。前端请求走MockMvc发出去然后断言响应结果。不过对启动时间有要求的话优先用对应的切片注解。另一个实用配置是spring-boot-starter-test自带的AssertJ。它的链式断言写起来比JUnit原生断言舒服很多比如assertThat(result.getCode()).isEqualTo(200); assertThat(userList).hasSize(3).extracting(User::getName).contains(张三);测试专属配置方面可以在application.yml里加spring.test.context.cache.maxSize控制上下文缓存数量。遇到上下文缓存导致内存溢出的场景可以适当调大这个值但不要盲目调缓存太多同样会拖累性能。3.2 WebMvcTest实操——只测Controller层我用一个订单查询接口来演示。假设有这样一个ControllerRestController RequestMapping(/api/orders) public class OrderController { private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService orderService; } GetMapping(/{id}) public ResponseEntityOrderDetailVO getOrderDetail(PathVariable Long id) { return ResponseEntity.ok(orderService.findDetail(id)); } }要测这个Controller直接用WebMvcTest指定这个控制器WebMvcTest(OrderController.class) class OrderControllerTest { Autowired private MockMvc mockMvc; MockBean private OrderService orderService; Test void shouldReturnOrderDetail() throws Exception { OrderDetailVO detail new OrderDetailVO(); detail.setOrderNo(NO20240001); when(orderService.findDetail(1L)).thenReturn(detail); mockMvc.perform(get(/api/orders/1)) .andExpect(status().isOk()) .andExpect(jsonPath($.orderNo).value(NO20240001)); } }这个测试里的关键点在WebMvcTest(OrderController.class)指定了具体控制器上下文只包含OrderController这一个Controller其他不相关的Controller不会加载。MockBean把OrderService替换成了Mock对象测试里用when、thenReturn定制行为。如果Controller里引用了全局异常处理类记得把对应的ControllerAdvice也加到切片范围里或者通过Import导入。否则请求返回的异常响应结构测不准确。我自己踩过这个坑全局异常处理器没导入测试里期望返回{code:500}实际却拿到了Spring默认的错误页格式。3.3 DataJpaTest实操——用真实SQL验证数据访问层数据访问层测试我倾向用DataJpaTest加内嵌数据库。默认情况下Spring Boot会尝试用嵌入式数据库替换真实数据源H2用得最多。仓库方法的测试逻辑可以这样写DataJpaTest class OrderRepositoryTest { Autowired private OrderRepository orderRepository; Test void shouldFindOrderByOrderNo() { Order order new Order(); order.setOrderNo(NO20240001); orderRepository.save(order); assertThat(orderRepository.findByOrderNo(NO20240001)).isPresent(); } }DataJpaTest默认开启事务每个测试方法结束后回滚不会污染真实数据库。这一点对测试稳定性很重要不需要手动清理数据。需要注意Repository方法名解析出的SQL和实际数据库方言是否匹配内嵌数据库能过不代表生产数据库一定能过。H2和MySQL在分页、字符集、锁和某些函数上的行为差别很大。我建议有条件的话再跑一组Testcontainers把真实数据库拉起来执行一遍数据访问层测试你会发现问题比想象中多。3.4 内置Mock与外部依赖的替换策略切片测试里一个很重要的技巧是外部依赖替换。比如某个接口依赖了Redis做缓存但WebMvcTest切片里RedisTemplate根本不在上下文测试又需要Redis参与逻辑。这个时候可以MockBean private RedisTemplateString, String redisTemplate;另一种方案是Import一个测试配置TestConfiguration static class RedisTestConfig { Bean ConditionalOnMissingBean RedisTemplateString, String redisTemplate() { return new RedisTemplate(); } }然后在测试类上加上Import(RedisTestConfig.class)。两种方式各有适用场景MockBean简单直接适合快捷打桩TestConfiguration适合需要真实Bean实现的场景比如自定义序列化器。另外提醒一下从Spring Boot 3.4开始MockBean已经被标记为deprecated虽然还能用但官方推荐用Mockito的Mock搭配InjectMocks或者手动构造测试对象。这个新趋势建议提前熟悉避免项目升级时大面积返工。4. 测试切片与JUnit 5集成时的高频坑4.1 测试切片里Bean加载不全怎么办最常见的问题在WebMvcTest里Autowired一个自定义的Service报出NoSuchBeanDefinitionException。原因就是上面说的切片上下文只加载MVC相关BeanService不在这个范围。排查思路是先看报错信息里提示的Bean类型再确认它是否属于当前切片的自动配置范围。如果确实需要它优先用MockBean模拟如果这个Bean影响的是配置逻辑可以考虑用Import导入到测试上下文。还有一个细节要留意Component和Configuration在切片上下文里的行为不同。某些切片的自动配置不会扫描Configuration以外的组件如果测试里出现了“明明加了配置类却完全不生效”的情况先检查一下是不是把配置类写成了普通组件。4.2 上下文缓存命中与状态污染Spring TestContext会对配置相同的测试上下文做缓存。相同配置指的是相同的测试类结构、相同的注解集合、相同的系统属性等。如果两个测试类一个加了WebMvcTest另一个也加了WebMvcTest但指定了不同的Controller它们会生成不同的缓存键上下文不会共享。缓存有一个常见副作用一个测试里改了静态变量或者单例Bean的状态后面复用到这个上下文的测试会拿到被污染的状态。我踩过一个坑线程池Bean里初始化了一个计数器某个测试触发后没清理另一批测试一进来就看到脏数据断言结果飘忽不定。解决办法是尽量让Bean无状态或者在该测试类上使用DirtiesContext。但要注意DirtiesContext会让缓存失效频繁使用会导致上下文反复创建反而降低性能。能用DirtiesContext的地方尽量收敛到少数几个需要隔离场景的测试方法上。4.3 数据库方言和ID生成策略不一致DataJpaTest默认用H2替换真实数据库执行速度确实快但也掩盖了一些方言差异。H2支持很多MySQL方言特性但分页、JSON字段、函数、全文索引这些方面仍然有差异。比如某些项目用了MySQL的JSON_EXTRACT在H2里行为就完全不同。ID生成策略也会有差异。MySQL的IDENTITY和H2的默认序列在saveAndFlush之后返回的自增ID行为不一样。如果测试断言依赖具体ID值H2和MySQL会得到不同结果。应对思路是分层验证日常开发用H2保证反馈速度硬件允许的话单独跑一组Testcontainers测试专门覆盖方言敏感的场景。这组测试可以放到单独的profile里按需执行。4.4 日志与异常输出的干扰切片测试把上下文缩小后很多自动配置的日志输出和行为会变化。最典型的是WebMvcTest跑的时候打印的安全过滤器日志以及HikariCP连接池的空闲连接警告。如果项目接入了日志上报组件测试期间日志被反复上报会拖慢整体测试速度。我习惯在test/resources下放一个专门的日志配置把测试日志级别调低关闭上报通道。另一个坑是MockMvc的异常处理默认情况下异常堆栈会输出到控制台有些测试因为期望异常结果反而被堆栈刷屏可以在配置里加AutoConfigureMockMvc(print MockMvcPrint.NONE)关掉打印保留断言本身。4.5 从JUnit 4迁移到JUnit 5时的兼容性老项目要从JUnit 4升级到JUnit 5除了依赖替换代码层面涉及几个点Before、After变为BeforeEach、AfterEachRunWith(SpringRunner.class)变为ExtendWith(SpringExtension.class)Rule相关功能大多改为内置支持比如临时目录用TempDir断言类从org.junit.Assert换成org.junit.jupiter.api.Assertions有一个容易忽略的地方assertThat静态引入的包路径变了从org.junit.Assert变成org.hamcrest.MatcherAssert或者AssertJ的org.assertj.core.api.Assertions。旧代码里大量使用Hamcrest的assertThat时迁移要同步调整不然编译报错会把人整崩溃。整体迁移建议分步走先加依赖启动JUnit Platform再用IDE的迁移工具做代码级替换最后逐步清理旧的Runner和Rule。不要指望一次迁移全部搞定分批推进最稳。5. 关于测试策略我想说点实际经验我自己的习惯是把测试分成三层纯单元测试只测方法逻辑完全不碰Spring容器切片测试负责分层集成保证层与层之间的接口约定正确全量集成测试只保留几条核心链路比如用户注册到下单这样跨模块的完整流程。这样全量跑一遍时间能控制在几分钟内日常开发主要靠第一、二层反馈。测试切片不是银弹它确实有一些边界问题需要处理比如方言差异、Bean加载范围、上下文缓存状态这些。但它确实能把“跑不动”的项目从泥潭里拽出来。如果你现在正被慢吞吞的测试套件折磨建议从切片测试入手先把单个模块的测试时间打下来再慢慢把边界梳理清楚。最后提醒一句测试代码也是项目资产值得像生产代码一样认真对待。