开头部分做Spring Boot开发这么多年我最怕的不是业务复杂度而是看着项目里的测试代码从“有”变成“有了也白有”。很多人把测试当成上线前的应付差事写出来的用例要么跑一次要五分钟要么依赖本地的MySQL和Redis要么mock了一大堆结果连自己都不知道在测什么。Spring Boot本身已经给了我们一套相当完整的测试生态但如果不理解它的设计意图很容易用歪。这篇内容我会从实际项目出发把Spring Boot Test的常用姿势和背后的原理一起讲清楚。覆盖单元测试、测试切片、集成测试、外部依赖模拟、测试数据管理等完整链路既有可直接复刻的代码片段又有我在多个项目中踩过的坑和总结出的避雷清单。无论你是刚接触测试的新手还是已经被慢速、不稳定的测试折磨到怀疑人生的老手这篇都值得你静下心来读一遍。1. 为什么Spring Boot测试需要一套“最佳实践”1.1 那些年我们写过的“假测试”先聊几个我见过的真实场景。场景一有人用SpringBootTest启动完整应用然后调HTTP接口做验证一个测试类跑下来要等几十秒整个测试套件动不动十几分钟CI上经常超时。场景二有人为了测试Service层方法在测试里连了生产环境的数据库副本数据一乱测试就莫名其妙飘红。场景三Controller测试里把Service层整个mock掉断言完请求参数就算了But业务异常路径没人测。这三个场景本质上是一个问题没有搞明白测试的目的。测试不是为了给代码库凑一个覆盖率数字而是为了在需求变更、代码重构时能快速给出“这件事有没有被破坏”的确定性答案。如果你写的测试跑得慢、不稳定、脱离真实逻辑那它非但不能给你确定性反而会成为团队的负担。你会发现没人愿意改测试代码改了业务代码必须同步改一堆用例最后大家默契地选择跳过测试直接提交。这比没有测试更危险。Spring Boot Test的最佳实践核心就是回答三个问题测什么层、用什么样的上下文、怎么样让测试足够快且足够可信。这三个问题想清楚了大部分测试混乱都能避免。1.2 这套实践覆盖的范围与适用场景我这篇内容的侧重点不是教你写某一个特定的测试而是给你一套分层清晰的方案。这套方案会在不同层级使用不同的测试手法Repository层用切片测试验证SQL和数据映射Service层用纯单元测试保证业务规则正确Controller层用MockMvc验证接口契约和异常返回涉及真实数据库、真实外部系统时再用Testcontainers做轻量级集成验证。整个体系的目标是让简单测试保持轻量让复杂测试可控让整个套件在几分钟内能跑完。这套实践里面的技巧适用范围很广典型的Web项目、微服务、需要对接第三方SDK或HTTP服务的项目比如我在一个对接大华SDK的实时监控项目里遇到过、依赖MySQL/PostgreSQL等数据库的生产应用、甚至带定时任务和消息队列的项目。无论你的Spring Boot应用长什么样分层的测试策略和工具选型的逻辑都是通用的。2. 测试基建与工具选型2.1 Spring Boot Test生态自带的东西已经够用先理清楚Spring Boot带给我们的测试基础设施。引入spring-boot-starter-test依赖之后JUnit 5、Mockito、AssertJ、Hamcrest、JsonPath、Awaitility这些组件就已经全部在内了。很多人不知道这几个库分别用来干什么这里简单理一遍JUnit 5测试框架的基础。提供Test、BeforeEach、AfterEach这些生命周期注解以及参数化测试、嵌套测试这些高级能力。MockitoJava领域最常用的mock库。用来创建假对象定义对象方法的行为并验证方法调用关系。AssertJ流式断言库。它提供的assertThat(...)链式写法比JUnit自带的断言好用得多失败信息也更直观。Hamcrest老牌匹配器库Matcher风格。在新项目中它的存在感被AssertJ削弱了但老项目里依然常见。JsonPath用于解析和断言JSON响应。在Controller测试里做JSON断言时非常顺手。Awaitility异步测试利器。可以轮询等待某个条件成立多用于验证异步任务、消息监听、定时任务等。总结起来Spring Boot的starter-test已经为你配齐了一个现代Java测试项目需要的全部基础能力。真正需要你额外选择的是外部依赖怎么处理的问题数据库用什么、下游HTTP接口怎么模拟、缓存和消息中间件怎么解决。2.2 数据库与外部依赖H2、Testcontainers、MockWebServer这是我在项目中被问得最多的部分测试数据库到底用H2还是用Testcontainers跑真实数据库没有绝对答案看场景。H2内存数据库最大的优势是启动极快测试用例运行起来和本地开发几乎无感。但它的问题也很突出H2的方言和真正的生产数据库比如MySQL、PostgreSQL存在差异一些生产环境的SQL特性在H2里跑不过去反过来H2里能跑的SQL到了生产环境又可能出错。尤其是项目里用到JSON字段、窗口函数、空间数据、特定的索引语法时H2往往力不从心。Testcontainers是另一种思路使用Docker容器在测试前启动一个和生产环境相同版本的真实数据库。这样能确保SQL行为完全一致。代价是Docker启动一个数据库容器需要几秒钟比H2慢不少而且团队开发机必须有Docker环境。我的建议很简单本地单元级别的Repository测试可以用H2或者直接用Testcontainers二选一即可。但如果你们项目里的SQL足够复杂或者有过“开发库正常、测试库正常、生产环境挂了”的经历直接上Testcontainers更稳妥。很多团队为了两头兼顾会在本地用Testcontainers、在CI里也跑Testcontainers牺牲一点启动时间来换取最终环境的一致性。至于外部HTTP接口的依赖我比较推荐MockWebServerOkHttp家的库。它可以理解为“在本机启动一个假的HTTP服务”测试代码可以预先定义接口返回什么样的JSON、HTTP状态码是多少测试结束时还能校验你的服务到底发出了什么请求。这比直接用Mockito mock掉HTTP客户端要真实得多因为整条HTTP通信链路——请求构造、序列化、响应反序列化——都被真实的代码路径覆盖到了。2.3 测试配置的管理application-test.yml与DynamicPropertySource测试环境必须有独立的配置这一点没什么好争论的。在src/test/resources下放一个application-test.yml配置测试用的数据源、日志级别、缓存策略。然后用ActiveProfiles(test)在测试类上激活它。这样做的好处是测试环境与本地开发、生产环境完全隔离不污染任何真实配置。Testcontainers场景下我通常会使用DynamicPropertySource。举个例子Testcontainers启动一个容器后数据库的端口是随机分配的没办法预先写死在配置文件中。这时候DynamicPropertySource可以在Spring上下文创建前把容器暴露出来的端口动态地注入到Spring Environment中SpringBootTest Testcontainers class OrderServiceIntegrationTest { static PostgreSQLContainer? postgres new PostgreSQLContainer(postgres:16-alpine); DynamicPropertySource static void configureProperties(DynamicPropertyRegistry registry) { registry.add(spring.datasource.url, postgres::getJdbcUrl); registry.add(spring.datasource.username, postgres::getUsername); registry.add(spring.datasource.password, postgres::getPassword); } }这种方式我实际用下来非常顺手不需要准备额外的测试配置文件每个测试类使用的数据库版本、初始化脚本都是自己控制的测试之间的隔离性也更强。3. 核心注解与分层测试范式3.1 SpringBootTest全量上下文的边界在哪里SpringBootTest是最直观的测试注解它会启动完整的Spring应用上下文加载所有的Bean、配置文件、自动配置。在集成测试中这很重要但很多人的问题是“每个测试类都在用SpringBootTest”这就不对了。全量上下文意味着Spring会实例化应用里几乎所有的组件。假设你的项目里有定时任务、消息监听器、Kafka消费者这些组件在SpringBootTest里都会被创建和启动。一旦其中某个组件依赖真实的中间件而测试环境又没有等你看到NoSuchBeanDefinitionException或者ConnectionRefusedException的时候浪费的几分钟已经回不来了。就算所有依赖都能满足每次加载上下文也需要好几秒——注意Spring TestContext框架会缓存相同配置的上下文所以如果多个测试类配置完全相同实际只有第一个类会真正启动但这依然挡不住不同配置组带来的额外加载成本。我的决策原则是这样的只需要测试某个Controller的请求映射、参数校验和响应结构时用WebMvcTest不要全量上下文。只需要测试JPA Repository的数据访问逻辑时用DataJpaTest不要全量上下文。需要验证SpringBootApplication入口、完整过滤器链、全局异常处理器、Bean装配正确性时才用SpringBootTest。把全量上下文当作一种“重武器”只在你真正需要验证整个应用的装配和协作时使用而不是默认选项。3.2 测试切片WebMvcTest与DataJpaTest的正确使用姿势测试切片是Spring Boot非常有特色的能力。它的本质是只加载应用上下文中的一部分Bean把测试范围限制在某一层。WebMvcTest专注于Web层它会扫描Controller、ControllerAdvice、JsonComponent等组件但不会加载Service层和Repository层的Bean。如果你在测试类里直接注入一个Service接口Spring找不到实现类就会报错。这时候就需要用MockitoBean去模拟Service层WebMvcTest(BookController.class) class BookControllerTest { Autowired MockMvc mockMvc; MockitoBean BookService bookService; Test void shouldReturnBookById() throws Exception { when(bookService.findBookById(1L)) .thenReturn(new BookVO(1L, Spring Boot实战)); mockMvc.perform(get(/api/books/1)) .andExpect(status().isOk()) .andExpect(jsonPath($.name).value(Spring Boot实战)); } }WebMvcTest跑起来非常快因为它不去初始化Service、Repository、消息队列只验证接口层的契约。适合用来测试参数绑定PathVariable、RequestParam、RequestBody、数据校验Valid、异常处理RestControllerAdvice和JSON序列化结果。DataJpaTest则专注于数据访问层。它会扫描Entity和Spring Data JPA Repository接口默认使用嵌入式数据库如果在classpath里能找到H2的话并且每个测试方法默认包裹在事务里测试结束后自动回滚不会污染数据库环境。DataJpaTest class BookRepositoryTest { Autowired BookRepository bookRepository; Test void shouldFindBooksByAuthorName() { Book book new Book(Spring Boot实战, 张三); bookRepository.save(book); ListBook books bookRepository.findByAuthor(张三); assertThat(books).hasSize(1); } }使用切片测试要注意一个细节DataJpaTest默认只加载Repository层和JPA相关组件不会加载你自己写的Component、Service。如果你的Repository里注入了其他自定义组件这个测试就会失败需要在测试类上用Import显式导入。3.3 MockBean与MockitoBeanmock的边界与版本差异Mock是单元测试绕不开的话题。Spring Boot中常见的两个注解是MockBean和MockitoBean。如果你用的是Spring Boot 3.4及以上版本官方已经把MockBean标记为废弃推荐使用MockitoBean它们的能力几乎相同只是在Bean的后处理流程和与Mockito框架的集成方式上有细微差别。老项目里继续用MockBean也能正常工作不必急着升级。但我想强调的是mock的边界问题。有一次我在审查代码时发现同事把Service层的测试写成了这样mock掉了Repositorymock掉了外部接口然后在when(service.doSomething()).thenReturn(...)——等等service就是被测试的目标你mock它干嘛这种测试基本等于没写它只验证了“一个被mock掉的方法在调用时返回了预设值”业务逻辑中的判断分支、异常处理完全没覆盖。正确的mock边界应该是被测试的类必须是真的它依赖的边界对象外部接口、数据访问层、消息队列客户端可以mock。Service层测试Service类本身用真实实例它依赖的Repository和第三方Client用Mockito来mock。Controller层测试Controller是真的Service层mock掉。这样每一个测试用例都能聚焦在当前层的业务逻辑上不混入其他层的实际行为。4. 实操一套可复刻的分层测试代码这一部分我准备用一个简单的图书管理REST接口作为示例项目把Repository层到集成测试依次走一遍。你可以把它当作一个最小可复制的模板替换成你自己的业务代码。4.1 Repository层测试验证数据访问逻辑Repository层的测试目标很单纯SQL语法对不对、Spring Data JPA的派生查询方法是否按预期工作、实体映射是否准确。我用DataJpaTest来跑这一层配合AutoConfigureTestDatabase(replace Replace.NONE)这个配置可以避免Spring把数据源替换成内嵌数据库DataJpaTest AutoConfigureTestDatabase(replace AutoConfigureTestDatabase.Replace.NONE) class BookRepositoryTest { Autowired private BookRepository bookRepository; Test void findAvailableBooks_shouldReturnOnlyBooksWithQuantityGreaterThanZero() { Book book1 Book.builder().title(Spring Boot实战).author(张三).quantity(3).build(); Book book2 Book.builder().title(深入理解Java虚拟机).author(李四).quantity(0).build(); bookRepository.saveAll(List.of(book1, book2)); ListBook availableBooks bookRepository.findByQuantityGreaterThan(0); assertThat(availableBooks) .extracting(Book::getTitle) .containsExactly(Spring Boot实战); } }测试方法本身很简单。值得提的是这里的实体构建方式如果你的实体存在大量必填字段我强烈建议为测试环境单独写一个测试数据工厂而不是在每个测试方法里手动new实体再逐个set。一个TestDataFactory类可以集中管理测试数据的默认值后续加字段了你只需要改一处而不是全局搜索所有new场景。在DataJpaTest场景下每个测试方法默认开启事务并回滚。这意味着如果你在测试方法里save了一条数据方法执行完后这条数据不会真的落地。这给测试带来了很好的隔离性不会被上一次运行的脏数据影响。但有个坑事务回滚对“真实SQL行为”存在一定掩盖。例如某些数据库在事务提交前不会真正校验外键约束这取决于隔离级别和数据库实现如果你依赖这种提交时抛异常的行为DataJpaTest可能测不出来。对于这种场景可以用Testcontainers跑一个不带事务回滚的真实集成测试。4.2 Service层测试核心业务规则验证Service层是业务逻辑最集中的地方也是测试收益最高的地方。我习惯用纯单元测试来做Service层的验证直接使用ExtendWith(MockitoExtension.class)不加载任何Spring上下文因此执行速度极快一般几十毫秒就跑完一个方法。ExtendWith(MockitoExtension.class) class BookServiceTest { Mock private BookRepository bookRepository; InjectMocks private BookService bookService; Test void borrowBook_shouldThrowExceptionWhenBookNotAvailable() { Book book Book.builder().title(Spring Boot实战).quantity(0).build(); when(bookRepository.findByIsbn(978-7-111-12345-6)) .thenReturn(Optional.of(book)); assertThatThrownBy(() - bookService.borrowBook(978-7-111-12345-6)) .isInstanceOf(BusinessException.class) .hasMessageContaining(库存不足); } }这里有几个关键点值得展开。第一InjectMocks会将被标注的类实例化并把Mock生成的对象注入进去。BookService内部依赖的接口只需要声明成字段就行。第二用assertThatThrownBy做异常断言时我建议连异常消息一起验证只断言异常类型在很多场景下并不足以说明逻辑正确。第三mock的粒度问题如果一个测试方法里需要when的调用超过了三四个而且是串起来的一大串那可能意味着你的被测方法设计得过于复杂可以考虑拆方法或者引入中间层而不是硬着头皮去模拟整条链路。Service层测试还需要注意一个细节不要直接mock一个内部方法之后再以“验证顺序”的方式写出过于脆弱的测试。比如验证某个方法里依次调用了repository.save、auditLogService.record、messagePublisher.publish这种顺序断言在后续重构时极其容易破裂收益却很低。我更建议把关注点放在“业务结果是否符合预期”上比如异常有没有抛、返回值对不对、依赖对象有没有收到关键的调用参数。4.3 Controller层测试接口契约与异常路径Controller层的测试核心是接口契约。用WebMvcTest加上MockMvc我可以验证URL路由、HTTP方法、参数解析、请求体校验、响应的JSON结构、以及异常时返回的状态码和错误信息格式。WebMvcTest(BookController.class) class BookControllerTest { Autowired private MockMvc mockMvc; MockitoBean private BookService bookService; Test void createBook_shouldReturn400WhenTitleIsBlank() throws Exception { String invalidPayload { title: , author: 张三, quantity: 1 } ; mockMvc.perform(post(/api/books) .contentType(MediaType.APPLICATION_JSON) .content(invalidPayload)) .andExpect(status().isBadRequest()) .andExpect(jsonPath($.message).value(书名不能为空)); } Test void createBook_shouldReturn201AndCreatedBook() throws Exception { BookVO created new BookVO(1001L, Spring Boot实战, 张三, 1); when(bookService.createBook(any(BookCreateCommand.class))) .thenReturn(created); mockMvc.perform(post(/api/books) .contentType(MediaType.APPLICATION_JSON) .content( { title: Spring Boot实战, author: 张三, quantity: 1 } )) .andExpect(status().isCreated()) .andExpect(jsonPath($.id).value(1001)) .andExpect(jsonPath($.title).value(Spring Boot实战)); } }第一个测试验证的是参数校验。Spring MVC的Valid注解在参数校验失败时会抛出MethodArgumentNotValidException如果项目里配置了全局异常处理器MockMvc会把请求一直送到异常处理器的出口。这样就顺带验证了全局异常处理器的返回格式是很重要的一条链路。第二个测试走的是正常创建流程。注意我用any(BookCreateCommand.class)来匹配参数这样即使Controller在将JSON转换为Command对象时有细微的字段差异也不会影响Service层的mock行为。断言响应时用的jsonPath是JsonPath语法连续调用几个断言就能把响应结构的关键字段都校验到位。在Controller测试中还有一个容易踩的坑默认情况下WebMvcTest不会加载Spring Security的配置以外的自定义安全过滤器链。如果你的项目接了Spring Security建议在测试类上加上AutoConfigureMockMvc(addFilters false)来跳过过滤器链专注于Controller本身的行为。安全相关逻辑单独用专门的Security测试类去覆盖不要把两件事混在一起。4.4 全链路集成测试真实数据库与端到端验证分层测试能覆盖大部分场景但有些问题只有完整的应用上下文和真实依赖才能暴露出来。比如Repository层的方法和Service层的事务注解在一起是否真的能正确工作Controller层的DTO转换和Repository层的实体映射在整条链路里是否匹配配置文件里的连接池参数和数据库容器是否兼容这些问题需要集成测试来回答。我通常的做法是SpringBootTest(webEnvironment SpringBootTest.WebEnvironment.RANDOM_PORT)搭配Testcontainers启动真实的数据库容器然后用TestRestTemplate或MockMvc发起完整的HTTP请求让它走完从Controller到Repository的全链路。SpringBootTest(webEnvironment SpringBootTest.WebEnvironment.RANDOM_PORT) Testcontainers ActiveProfiles(test) class BookApiIntegrationTest { Container static PostgreSQLContainer? postgres new PostgreSQLContainer(postgres:16-alpine) .withDatabaseName(bookstore) .withUsername(test) .withPassword(test); Autowired private TestRestTemplate restTemplate; DynamicPropertySource static void configurePostgres(DynamicPropertyRegistry registry) { registry.add(spring.datasource.url, postgres::getJdbcUrl); registry.add(spring.datasource.username, postgres::getUsername); registry.add(spring.datasource.password, postgres::getPassword); } Test void borrowBook_shouldSucceedWhenBookIsInStock() { BookCreateRequest request new BookCreateRequest(Spring Boot实战, 张三, 2); Long bookId restTemplate.postForObject(/api/books, request, BookVO.class).getId(); restTemplate.put(/api/books/{id}/borrow, null, bookId); BookVO book restTemplate.getForObject(/api/books/{id}, BookVO.class, bookId); assertThat(book.quantity()).isEqualTo(1); } }这里的webEnvironment RANDOM_PORT非常关键。每个测试类启动时会随机分配一个可用端口避免多个测试类互相占用端口也避免和开发环境本地启动的应用端口冲突。TestRestTemplate会自动感知随机端口不需要你手动拼URL。Testcontainers配合Container和Testcontainers注解时有个重要的使用细节静态字段上的容器会被类的所有测试方法共享并且会复用同一个容器实例如果不用static每个测试方法都会创建一个新容器测试时间会成倍增加。除非你有特殊的隔离需求否则一律声明为static。4.5 外部HTTP依赖测试用MockWebServer模拟下游在对接第三方服务时测试的核心挑战是你不能在测试环境随随便便地真正调用对方的接口。比如我之前在做大华SDK实时监控集成时SDK本身还需要对接摄像头设备的HTTP接口测试环境根本没有设备可用。这时候MockWebServer就是救星。它可以作为本地HTTP服务替你返回预定义的响应让你验证自己的代码在下游各种响应下是否行为正确。ExtendWith(MockitoExtension.class) class DeviceApiClientTest { private MockWebServer mockWebServer; private DeviceApiClient deviceApiClient; BeforeEach void setUp() throws IOException { mockWebServer new MockWebServer(); mockWebServer.start(); String baseUrl http://localhost: mockWebServer.getPort(); deviceApiClient new DeviceApiClient(baseUrl, new RestTemplate()); } AfterEach void tearDown() throws IOException { mockWebServer.shutdown(); } Test void getDeviceStatus_shouldHandleServerError() { mockWebServer.enqueue(new MockResponse() .setResponseCode(500) .setBody(Internal Server Error)); assertThatThrownBy(() - deviceApiClient.getDeviceStatus(DEV-001)) .isInstanceOf(RemoteServiceException.class) .hasMessageContaining(500); } }MockWebServer的使用模式非常固定启动服务、enqueue预设响应、发起请求、断言结果。它的强大之处在于除了能验证你的代码对错误响应的处理还能在测试结束时检查“你的代码是否真的发出了预期的请求”。比如你可以用RecordedRequest获取请求路径、请求头、请求体内容做断言这在排查请求参数构造错误时极其有用。在集成测试中如果你不想直接用MockWebServer也可以考虑用MockBean去替换真正的HTTP客户端Bean。不过我更推荐MockWebServer方案因为它能做到更接近真实的端到端验证HTTP序列化、连接池管理这些环节都能被覆盖到。5. 测试数据管理与执行效率优化5.1 测试数据隔离事务回滚、Sql与数据工厂测试数据的管理直接影响测试的稳定性。最经典的例子是某个测试往用户表插入了一条数据没有清理干净另一个测试再跑的时候查到两条数据断言失败然后全组排查半天发现是数据污染。要解决这个问题一般有几种手段。第一种是依赖DataJpaTest自带的事务回滚简单粗暴且有效。第二种是使用Sql注解在测试方法执行前插入数据、执行后清理数据Test Sql(scripts {/sql/insert_book.sql}, executionPhase Sql.ExecutionPhase.BEFORE_TEST_METHOD) Sql(scripts {/sql/clean_book.sql}, executionPhase Sql.ExecutionPhase.AFTER_TEST_METHOD) void shouldFindBookAfterFixtureLoaded() { // 测试逻辑 }Sql的优点是直观脚本文件集中管理对于复杂的历史数据准备场景非常有用。但缺点也很明显SQL脚本和Java代码分离改字段时要记得同步改脚本维护成本会逐渐上升。第三种是我个人最推荐的方式写一个测试数据工厂类专门负责构造测试数据和默认值。这个方法比Sql更符合面向对象思维比手写new实体的方式更可控public class BookTestFactory { private static final AtomicLong idGenerator new AtomicLong(1); public static Book newBook() { return Book.builder() .title(默认书籍) .author(默认作者) .quantity(10) .isbn(978- idGenerator.getAndIncrement()) .build(); } public static Book newOutOfStockBook() { return Book.builder() .title(默认书籍) .author(默认作者) .quantity(0) .isbn(978- idGenerator.getAndIncrement()) .build(); } }注意isbn这里用了一个自增的id这是为了避免数据库里唯一约束的冲突。很多团队在测试数据工厂上栽过跟头就是因为测试数据里硬编码了固定值多个测试类同时插入时冲突不断。使用生成器或者UUID能彻底绕开这个坑。5.2 测试执行速度与稳定性上下文缓存与并行策略Spring的TestContext框架会缓存测试上下文。默认情况下多个测试类如果使用了完全相同的配置相同的注解、相同的配置类、相同的ActiveProfiles它们会共享同一个Spring ApplicationContext实例不会重复初始化。这是Spring Boot测试能跑得快的一个重要机制。但上下文缓存有几个容易踩的坑。一是MockitoBean的定义会影响上下文。两个测试类的mock Bean定义不一样缓存就会被分离导致Spring额外创建一份上下文速度立刻降下来。二是DynamicPropertySource的动态属性如果来自Testcontainers容器则每次启动的端口都不同这会导致上下文缓存永远无法命中。对于这种情况可以考虑在同一个集成测试类里存放多个相关的集成测试方法而不是拆到多个测试类减少整体上下文数量。并行测试是提升速度的另一个方向。JUnit 5支持并行执行测试方法但是要谨慎开启。如果测试之间共享了数据库资源并行执行可能会导致数据竞争如果共享了MockWebServer端口也有冲突风险。我的建议是先在单模块里把测试速度控制在可接受范围不要一开始就上并行。等测试套件膨胀到实在跑不动了再考虑用Gradle或Maven的并行执行分配多个JVM进程来跑不同模块的测试这样隔离性更高稳定性也更好。5.3 测试命名与团队约定测试代码首先是给人读的。我见过很多测试方法叫testAdd、testQuery完全看不出测试的业务意图这是非常糟糕的实践。我推荐使用should_when风格的方法命名例如shouldThrowException_whenBorrowOutOfStockBookshouldReturnBook_whenBookExistsshouldReturn400_whenTitleIsBlank这种命名的好处是断言先行行为后置。读测试方法名就能明白这个测试想保证什么业务规则即使测试方法内部实现复杂也能从名字上抓住重点。在团队中我还会建议每个测试方法只聚焦一个行为假设如果方法里塞了太多不相关的断言未来排查失败原因时会很痛苦。6. 常见问题与排查技巧实录下面这组问题是我在多个项目里都遇到过的整理成一个速查表遇到相似问题可以直接对照排查。问题现象根本原因解决方案测试上下文加载非常慢每个测试类都要几十秒测试类配置不同上下文缓存被频繁击穿统一使用相同的ActiveProfilesmock Bean尽量一致减少不同配置的上下文数量测试方法1执行结果影响了测试方法2测试数据没有隔离依赖了数据库残留数据使用Transactional回滚或数据工厂生成唯一键或Sql清理数据本地测试能过CI上测试挂了CI环境缺少本地依赖如Docker、本地数据库所有外部依赖用Testcontainers管理确保CI能访问Docker测试里使用RANDOM_PORT但端口仍冲突代码里硬编码了server.port或使用了固定端口检查配置文件有没有硬编码端口移除application-test.yml里的server.portDataJpaTest里无法验证外键约束事务回滚导致提交时才会触发的约束未生效使用Testcontainers跑真实数据库且不包裹事务MockWebServer没有消费到预期的请求目标代码可能走了缓存或者请求路径不对使用mockWebServer.takeRequest()断言请求内容检查实际发送的URL和参数Testcontainers启动慢每次运行都拉镜像、创建新容器使用static容器字段预先拉取镜像利用Docker缓存再看两个我实际排查过的案例。某个项目里团队发现WebMvcTest的测试突然全部失败原因是有人在全局异常处理器里注入了UserService这个Service没有在测试切片中加载。解决方案是在测试类上通过MockitoBean UserService补上这个依赖。这个问题几乎每个用过测试切片的人都会遇到记住切片测试只加载Web层和它直接相关的Bean其他依赖需要你自己显式mock或导入。另一个案例更隐蔽。一个基于Spring Boot的消息消费项目平时测试都正常但某次提交后测试开始随机超时。排查发现有人在测试方法里启了一个真实的KafkaListener但Kafka测试容器时有时无导致监听器反复重连。最终方案是把消息消费逻辑抽象到独立组件中测试中只验证消息处理的核心方法而不是去验证Kafka监听器的生命周期。结尾在Spring Boot项目里把测试做好说到底就是不断在“快”和“真实”之间做取舍。测试切片提供了快Testcontainers提供了真实MockWebServer在你没有真实外部系统时给了你确定性测试数据工厂和事务回滚帮你把隔离性拉满。我个人踩过太多次“明明在本地能过但CI必挂”的坑后来发现绝大多数都是数据污染、上下文配置不一致或者依赖真实环境惹的祸。最后再分享一个我坚持了很久的小习惯每次写完业务代码先跑一遍对应的测试类再提交而不是把测试交给CI机器。当测试足够快的时候这个习惯几乎不增加任何负担但它能帮你把大部分问题拦截在提交之前。测试不是项目的成本它是你能放心重构和发布的底气。希望这篇文章能够帮你的Spring Boot项目把测试体系真正立起来别再为了凑覆盖率而写“假测试”了。