Spring Boot微服务测试实战：JUnit与Mockito分层测试策略解析

1. 项目概述：为什么微服务测试是门“手艺活”？

干了这么多年Java后端开发，从单体应用到微服务，我最大的感触就是：测试这事儿，在微服务架构里，从一个“可选项”彻底变成了“生存技能”。以前单体应用，一个mvn test跑完，心里大概就有底了。现在呢？服务拆得七零八落，服务A依赖B，B又调用C的接口，数据库、缓存、消息队列全搅和在一起。你写个新功能，本地一跑，好家伙，连不起来，因为依赖的服务没启动。这时候，一套扎实的、分层的测试策略，就是你手里最靠谱的“导航仪”。

Spring Boot作为微服务开发的“瑞士军刀”，把配置简化到了极致，但在测试上，它提供的是一套强大但需要你理解其“脾气”的工具集。核心就是JUnit和Mockito这对黄金搭档。JUnit是骨架，定义了测试该怎么组织、怎么运行；Mockito是肌肉和神经，让你能隔离复杂依赖，精准地测试你关心的那一小块逻辑。很多人觉得写测试就是加个@Test注解，然后assertEquals一下，这其实只摸到了皮毛。真正的价值在于，通过单元测试保证每个“零件”（类或方法）的质量，再通过集成测试验证这些“零件”组装起来后，接口、数据流、配置是否都能正确工作。

我见过不少项目，前期为了赶进度，测试能省则省，到了中后期，没人敢动祖传代码，每次上线都像在赌命。相反，那些测试覆盖率高、分层清晰的项目，重构、迭代都显得从容不迫。所以，今天我不讲那些教科书上的概念，就结合我这几年在Spring Boot微服务项目里摸爬滚打的经验，跟你聊聊怎么用JUnit和Mockito，把单元测试和集成测试写出“实战感”，写出能真正给你信心的代码。

2. 测试策略与核心工具选型背后的逻辑

在动手写第一行测试代码之前，得先想清楚测试的“地图”怎么画。在微服务语境下，我们通常谈的是“测试金字塔”。金字塔底层是量大、运行快的单元测试，中间是集成测试，顶层是端到端（E2E）测试。我们这里聚焦在JUnit和Mockito最能发挥作用的底层和中层。

2.1 单元测试：隔离与精准打击

单元测试的目标是验证单个类或方法的行为，前提是隔离。想象一下，你要测试一个OrderService的创建订单方法，这个方法内部会调用InventoryClient（检查库存）、PaymentClient（处理支付）和OrderRepository（保存订单）。如果你不隔离，这个测试就需要启动数据库、启动库存和支付服务，这已经不是单元测试了，它慢、不稳定、而且一旦失败你很难定位是OrderService的逻辑问题还是外部依赖的问题。

这就是Mockito的舞台。它的核心思想是“模拟”（Mock）和“打桩”（Stub）。你可以创建一个InventoryClient的模拟对象，并规定：“当调用checkStock方法时，返回true”。这样，OrderService就在一个完全可控的环境下运行，测试只关注其业务逻辑：给定足够的库存和成功的支付，它是否正确地创建并保存了订单？为什么选择Mockito而不是EasyMock之类的？社区活跃度、API的流畅度（特别是BDD风格的given...willReturn语法）以及与Spring生态（通过@MockBean）的无缝集成，让它成为了事实上的标准。

2.2 集成测试：组装与契约验证

单元测试保证了“零件”没问题，但零件拼装起来会不会出岔子？这就需要集成测试。在Spring Boot微服务中，集成测试通常指：

1. Web层集成测试：测试Controller的HTTP接口，包括URL映射、参数绑定、序列化/反序列化、过滤器、拦截器等。这里我们会用到Spring的MockMvc，它可以模拟HTTP请求，而不需要启动完整的Servlet容器（如Tomcat），速度很快。
2. 数据层集成测试：测试Repository与真实数据库（通常是内存数据库，如H2）的交互。验证JPA映射、查询语句是否正确。
3. 客户端集成测试：测试你的服务对外部服务（如其他微服务、第三方API）的调用逻辑。这里通常会用MockRestServiceServer来模拟外部服务的响应。

集成测试的关键是平衡。你希望测试尽可能真实的环境，但又不想测试变得太慢太笨重。所以，我们用内存数据库代替MySQL，用MockMvc代替真实Tomcat，用MockRestServiceServer代替真实的HTTP服务。Spring Boot的@SpringBootTest注解是启动集成测试的钥匙，它会根据你的配置，加载一个接近真实但做了优化的应用上下文。

2.3 工具链搭配：不止JUnit和Mockito

虽然主角是JUnit和Mockito，但一个好的测试环境还需要配角：

• AssertJ vs Hamcrest：用于更优雅、可读性更强的断言。我强烈推荐AssertJ，它的流式API（assertThat(actual).isEqualTo(expected).hasSize(10)）写起来非常顺手，错误信息也更清晰。
• JSONPath & JsonAssert：在测试REST API返回的JSON时，用于验证特定字段的值，比手动解析JSON字符串方便太多。
• Testcontainers：当内存数据库无法满足测试需求时（比如你要测特定的PostGIS函数或Redis集群命令），Testcontainers可以启动真实的Docker容器来运行数据库，这是迈向“生产环境对等”测试的强大工具，但会显著增加测试时间，需酌情使用。

选型的原则就一个：用合适的工具解决特定层次的问题，保持测试的快速、稳定和可维护性。

3. 单元测试实战：从Mock注入到行为验证

理论说再多，不如看代码。我们假设有一个简单的UserService，它依赖UserRepository和EmailService。

@Service public class UserService { private final UserRepository userRepository; private final EmailService emailService; public UserService(UserRepository userRepository, EmailService emailService) { this.userRepository = userRepository; this.emailService = emailService; } public User registerUser(String username, String email) { if (userRepository.findByUsername(username) != null) { throw new IllegalArgumentException("Username already exists"); } User user = new User(username, email); User savedUser = userRepository.save(user); emailService.sendWelcomeEmail(email); // 假设这个方法可能失败 return savedUser; } }

3.1 测试类结构与Mock注入

我们用JUnit Jupiter（JUnit 5）和Mockito来写这个单元测试。

import org.junit.jupiter.api.Test; import org.junit.jupiter.api.extension.ExtendWith; import org.mockito.InjectMocks; import org.mockito.Mock; import org.mockito.junit.jupiter.MockitoExtension; import static org.mockito.Mockito.*; import static org.assertj.core.api.Assertions.*; @ExtendWith(MockitoExtension.class) // 1. 启用Mockito支持 class UserServiceTest { @Mock // 2. 创建模拟对象 private UserRepository userRepository; @Mock private EmailService emailService; @InjectMocks // 3. 将模拟对象注入到被测试对象 private UserService userService; @Test void registerUser_WithNewUsername_ShouldSaveAndSendEmail() { // Given: 准备测试数据并定义模拟行为 String username = "testUser"; String email = "test@example.com"; User mockUser = new User(username, email); // 打桩：当调用userRepository.findByUsername时，返回null（表示用户不存在） when(userRepository.findByUsername(username)).thenReturn(null); // 打桩：当调用userRepository.save时，返回我们准备好的mockUser对象 when(userRepository.save(any(User.class))).thenReturn(mockUser); // 对于emailService.sendWelcomeEmail，我们假设它成功执行，不需要特殊打桩，默认就是“什么也不做” // When: 执行被测试方法 User result = userService.registerUser(username, email); // Then: 验证结果和行为 // 验证返回的用户正确 assertThat(result).isEqualTo(mockUser); // 验证userRepository.save被调用了一次，且参数是一个User对象 verify(userRepository, times(1)).save(any(User.class)); // 验证emailService.sendWelcomeEmail被调用了一次，且参数是特定的email verify(emailService, times(1)).sendWelcomeEmail(email); // 验证userRepository.findByUsername被调用了一次 verify(userRepository, times(1)).findByUsername(username); } @Test void registerUser_WithExistingUsername_ShouldThrowException() { // Given String existingUsername = "existingUser"; User existingUser = new User(existingUsername, "existing@example.com"); when(userRepository.findByUsername(existingUsername)).thenReturn(existingUser); // When & Then: 使用AssertJ的异常断言 assertThatThrownBy(() -> userService.registerUser(existingUsername, "new@example.com")) .isInstanceOf(IllegalArgumentException.class) .hasMessageContaining("Username already exists"); // 验证save和sendEmail方法没有被调用（因为异常提前抛出了） verify(userRepository, never()).save(any()); verify(emailService, never()).sendWelcomeEmail(anyString()); } }

关键点解析与避坑指南：

1. @ExtendWith(MockitoExtension.class)：这是JUnit 5的写法，替代了老旧的@RunWith(MockitoJUnitRunner.class)。它负责初始化Mockito注解。
2. @Mock与@InjectMocks：@Mock创建一个模拟对象。@InjectMocks会创建UserService的真实实例，并尝试将标注了@Mock（或@Spy）的字段通过构造函数（首选）、setter或字段注入的方式注入进去。这里有个大坑：如果你的UserService用的是@Autowired字段注入而不是构造器注入，@InjectMocks可能无法正确注入。最佳实践是始终使用构造器注入，这不仅利于测试，也是Spring官方推荐的方式。
3. Given-When-Then模式：这是一种结构清晰的测试编排模式，强烈建议遵循。让测试的意图一目了然。
4. when().thenReturn()vsdoReturn().when()：大部分情况下用前者。后者通常用于模拟void方法或绕过静态方法/私有方法（这本身是代码有坏味道的信号）。
5. 验证（Verification）：verify用来检查模拟对象的交互是否按预期发生。times(1)是默认值，可以省略。never()和atLeast(n)等也很常用。注意：不要过度验证。只验证与被测试方法核心逻辑相关的、有业务意义的交互。验证每个getter/setter调用会让测试变得脆弱。
6. “打桩”的细节：any(User.class)是一个参数匹配器（Argument Matcher），它表示“任何User类型的参数”。还有eq()（等于）、isNull()等。谨慎使用any()系列，有时过于宽松会掩盖问题。

实操心得：我习惯在“Then”部分，先对方法的返回值做断言，再验证交互。如果方法没有返回值（void），那么验证交互就是主要的断言手段。另外，给测试方法起一个描述性的名字，比如registerUser_WithNewUsername_ShouldSaveAndSendEmail，虽然长，但看了名字就知道这个测试在测什么场景、期望什么结果，维护起来非常方便。

3.2 处理棘手的依赖：静态方法、final类与void方法

现实代码不会总是那么“干净”。你可能会遇到工具类里的静态方法，或者第三方库里的final类。

• 静态方法（如LocalDateTime.now()）：直接模拟静态方法是困难的，通常说明你的代码设计有改进空间。可以考虑将时间作为参数传入，或者使用像Clock这样的可替换依赖。如果必须处理，可以借助Mockito-inline（从Mockito 3.4.0开始支持模拟静态方法）或PowerMock（较重，不推荐在新项目中使用）。
• Final类/方法：同样，Mockito（默认）无法模拟final类或方法。这通常是在提醒你，对第三方库的强耦合可能有问题。可以考虑用适配器模式（Wrapper）将其包裹一层，然后模拟你自己的适配器。如果别无选择，同样需要Mockito-inline的支持。
• Void方法：模拟void方法通常是为了验证它被调用了，或者模拟它抛出异常。

  // 模拟void方法调用 doNothing().when(emailService).sendWelcomeEmail(anyString()); // 模拟void方法抛出异常 doThrow(new RuntimeException("Network error")).when(emailService).sendWelcomeEmail(anyString());

核心原则：如果写单元测试时感到特别费力，需要动用各种“黑魔法”来模拟，这往往是代码本身“可测试性”差的一个信号。此时，重构代码可能比强行写测试更有价值。

4. 集成测试实战：构建接近真实的环境

单元测试把一切都Mock了，集成测试则要把一些真实的东西“装”回来。我们分场景来看。

4.1 Web层集成测试：用MockMvc测试Controller

假设我们有一个简单的UserController。

@RestController @RequestMapping("/api/users") public class UserController { private final UserService userService; // 构造器注入... @PostMapping public ResponseEntity<User> createUser(@RequestBody @Valid CreateUserRequest request) { User user = userService.registerUser(request.getUsername(), request.getEmail()); return ResponseEntity.status(HttpStatus.CREATED).body(user); } }

测试这个Controller，我们关心HTTP层面的行为：状态码、响应头、JSON格式。我们使用@WebMvcTest，它会切片加载只与Web层相关的Bean（Controller, ControllerAdvice, Filter等），不会加载完整的应用上下文，速度很快。

import org.springframework.beans.factory.annotation.Autowired; import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest; import org.springframework.boot.test.mock.mockito.MockBean; import org.springframework.http.MediaType; import org.springframework.test.web.servlet.MockMvc; import com.fasterxml.jackson.databind.ObjectMapper; import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.*; import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.*; @WebMvcTest(UserController.class) // 1. 只加载Web层相关的配置 class UserControllerTest { @Autowired private MockMvc mockMvc; // 2. 注入MockMvc，用于模拟HTTP请求 @Autowired private ObjectMapper objectMapper; // 3. JSON序列化工具 @MockBean // 4. 因为UserService是Controller的依赖，需要被Mock private UserService userService; @Test void createUser_WithValidRequest_ShouldReturn201() throws Exception { // Given CreateUserRequest request = new CreateUserRequest("newUser", "new@example.com"); User mockUser = new User("newUser", "new@example.com"); when(userService.registerUser(request.getUsername(), request.getEmail())) .thenReturn(mockUser); // When & Then mockMvc.perform(post("/api/users") // 5. 发起POST请求 .contentType(MediaType.APPLICATION_JSON) .content(objectMapper.writeValueAsString(request))) // 6. 设置JSON请求体 .andExpect(status().isCreated()) // 7. 断言状态码为201 .andExpect(jsonPath("$.username").value("newUser")) // 8. 使用JsonPath断言响应体JSON .andExpect(jsonPath("$.email").value("new@example.com")); verify(userService).registerUser(request.getUsername(), request.getEmail()); } @Test void createUser_WithInvalidRequest_ShouldReturn400() throws Exception { // 测试验证失败场景：请求体为空或字段不符合@Valid约束 mockMvc.perform(post("/api/users") .contentType(MediaType.APPLICATION_JSON) .content("{}")) // 空的JSON对象 .andExpect(status().isBadRequest()); // 断言400 Bad Request } }

关键点解析：

1. @WebMvcTest：这是针对Controller的切片测试注解，效率高。它会自动配置MockMvc。
2. MockMvc：模拟HTTP请求的核心工具。perform方法发起请求，andExpect用于断言结果。
3. ObjectMapper：Spring Boot会自动配置它，用于将对象序列化为JSON字符串作为请求体，或反序列化响应体。
4. @MockBean：注意这里是@MockBean，不是@Mock。@MockBean是Spring提供的，它会将Mockito模拟的对象注册到Spring的应用上下文中，替换掉原有的Bean。这是集成测试中Mock依赖的关键。
5. 请求构建：MockMvcRequestBuilders提供了get(),post(),put(),delete()等静态方法，可以链式调用设置请求头、参数、内容等。
6. JSON处理：务必设置正确的Content-Type，并将请求对象序列化为JSON字符串。
7. 结果断言：MockMvcResultMatchers提供了丰富的断言方法，如status(),content(),jsonPath(),header()等。jsonPath非常强大，可以像XPath一样定位JSON中的字段进行断言。
8. 验证交互：和单元测试一样，我们也可以在集成测试的最后验证Service层方法是否被正确调用。

4.2 数据层集成测试：使用真实数据库（H2）

测试UserRepository，我们需要一个真实的数据库环境。Spring Boot提供了@DataJpaTest注解。

import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest; import org.springframework.boot.test.autoconfigure.orm.jpa.TestEntityManager; import javax.persistence.EntityManager; import static org.assertj.core.api.Assertions.assertThat; @DataJpaTest // 1. 切片测试，只加载JPA相关的配置，默认使用内嵌数据库（如H2） class UserRepositoryTest { @Autowired private TestEntityManager testEntityManager; // 2. 用于测试的EntityManager，方便操作 @Autowired private UserRepository userRepository; @Test void findByUsername_WhenUserExists_ShouldReturnUser() { // Given: 使用TestEntityManager将数据持久化到测试数据库 User user = new User("johndoe", "john@example.com"); testEntityManager.persistAndFlush(user); // 立即持久化并同步到数据库 // When User found = userRepository.findByUsername("johndoe"); // Then assertThat(found).isNotNull(); assertThat(found.getEmail()).isEqualTo("john@example.com"); } @Test void findByUsername_WhenUserNotExists_ShouldReturnNull() { // When User found = userRepository.findByUsername("unknown"); // Then assertThat(found).isNull(); } }

关键点解析：

1. @DataJpaTest：它会自动配置一个内嵌数据库（默认H2），并扫描@Entity类和Spring Data JPA仓库。它默认会回滚事务，每个测试方法执行后数据都会被清理，保证测试隔离。
2. TestEntityManager：是EntityManager的测试专用版本，提供了一些便捷方法如persistAndFlush、find，用于在测试中准备数据或验证持久化状态。
3. 事务与回滚：@DataJpaTest标注的测试默认在每个方法后回滚。如果你需要提交数据（例如测试@Transactional(propagation = Propagation.NEVER)的场景），可以使用@Rollback(false)注解，但务必记得在测试后手动清理，以免影响其他测试。

注意事项：H2数据库和MySQL等生产数据库在语法、函数、约束上可能存在差异。如果你的查询使用了数据库特定的函数（如DATE_FORMAT），在H2中可能会失败。这时你有几个选择：1) 使用H2的兼容模式（在application-test.properties中配置spring.datasource.url=jdbc:h2:mem:testdb;MODE=MySQL）；2) 使用Testcontainers启动一个真实的MySQL测试容器；3) 重构代码，将数据库特定逻辑抽象出来。

4.3 完整集成测试：@SpringBootTest的应用

当你需要测试多个层之间的交互，或者测试使用了@ConfigurationProperties、自定义的Spring Bean等完整功能时，就需要@SpringBootTest。它会启动一个几乎和真实应用一样的上下文（但可以通过配置优化，比如不启动Web服务器，或使用特定的Profile）。

import org.springframework.boot.test.context.SpringBootTest; import org.springframework.boot.test.web.client.TestRestTemplate; import org.springframework.boot.test.web.server.LocalServerPort; import org.springframework.http.HttpStatus; import org.springframework.http.ResponseEntity; import org.springframework.test.context.ActiveProfiles; import static org.assertj.core.api.Assertions.assertThat; @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) // 1. 启动完整上下文，并使用随机端口 @ActiveProfiles("test") // 2. 激活`test` profile，使用测试配置（如连接H2数据库） class UserIntegrationTest { @LocalServerPort // 3. 注入随机分配的端口 private int port; @Autowired private TestRestTemplate restTemplate; // 4. 用于发起HTTP请求的测试客户端 @Test void fullIntegrationTest_CreateAndRetrieveUser() { // 配置测试数据库（可能需要通过Repository或SQL脚本初始化） // 这里假设我们有一个干净的H2数据库 CreateUserRequest request = new CreateUserRequest("integrationUser", "integration@example.com"); // 调用真实的HTTP接口 ResponseEntity<User> response = restTemplate.postForEntity( "http://localhost:" + port + "/api/users", request, User.class ); assertThat(response.getStatusCode()).isEqualTo(HttpStatus.CREATED); User createdUser = response.getBody(); assertThat(createdUser).isNotNull(); assertThat(createdUser.getUsername()).isEqualTo("integrationUser"); // 可以进一步调用GET接口验证用户是否已持久化 // ResponseEntity<User> getResponse = restTemplate.getForEntity(...); } }

关键点解析：

1. @SpringBootTest：这是最重量级的测试注解。webEnvironment有多种模式：
   • WebEnvironment.MOCK：默认值，加载一个Web应用的模拟环境，不启动真正的服务器。MockMvc通常与此模式搭配。
   • WebEnvironment.RANDOM_PORT：启动一个真实的嵌入式服务器（如Tomcat），并监听一个随机端口。适合需要测试网络层、过滤器链等完整HTTP栈的场景。
   • WebEnvironment.DEFINED_PORT：使用application.properties中定义的端口（如server.port）。
   • WebEnvironment.NONE：不提供任何Web环境，只加载应用上下文。
2. @ActiveProfiles(“test”)：这是管理测试配置的黄金法则。你需要在src/test/resources/下创建一个application-test.properties文件，里面配置测试专用的数据库连接（如H2）、关闭一些生产环境才需要的组件（如Swagger的认证）等。这能确保测试环境与生产环境隔离。
3. TestRestTemplate：是RestTemplate的测试友好版本，适合在集成测试中发起对真实端点的调用。它自动将响应体反序列化为对象。

性能考量：@SpringBootTest启动完整上下文很慢，应尽量避免在每次测试方法执行时都重新启动。可以通过使用@TestConfiguration提供特定的测试Bean，或者确保测试类设计合理，减少上下文重启次数。Spring Boot Test本身也有缓存机制，相同配置的上下文只会加载一次。

5. 测试中的常见“坑”与排查技巧

写了这么多测试，踩过的坑比写的测试用例还多。下面是一些典型问题和我的应对方法。

5.1 依赖注入失败：@MockBean与@Autowired的战争

问题：在集成测试中，你@Autowired了一个Bean，同时又用@MockBean定义了它的Mock，测试运行时发现注入的不是Mock，还是原来的Bean，或者直接报NoSuchBeanDefinitionException。

排查：

1. 检查包扫描：@SpringBootTest默认会扫描主应用类所在包及其子包。如果你的测试类不在这个范围内，或者你的Bean定义在特殊的配置类里，可能需要用@SpringBootTest(classes = {YourConfig.class})显式指定配置类。
2. Bean名称冲突：如果有多个同类型的Bean，@MockBean可能无法确定替换哪一个。可以指定Bean的名称：@MockBean(name = “specificService”)。
3. 构造器注入 vs 字段注入：再次强调，使用构造器注入能最大程度避免此类问题。如果被测试的Bean使用字段注入（@Autowired在字段上），Spring在创建该Bean时，@MockBean可能还未被应用到上下文中。使用@TestConfiguration内部类来显式定义Mock Bean有时能解决这个问题。

@SpringBootTest class SomeIntegrationTest { @TestConfiguration static class MockConfig { @Bean @Primary // 如果有多个同类型Bean，用@Primary让这个Mock优先 public SomeService someService() { return Mockito.mock(SomeService.class); } } // ... 测试代码 }

5.2 事务回滚与数据污染

问题：集成测试跑完，数据库里留下了测试数据，影响了后续测试或其他人的测试环境。

原因与解决：

• 默认行为：@SpringBootTest默认情况下，测试方法是在一个事务中运行的，方法结束后事务回滚。@DataJpaTest更是明确地回滚。
• 需要提交的情况：如果你测试的方法本身标注了@Transactional(propagation = Propagation.NEVER)或者你就是要测试事务提交后的状态，就需要禁用回滚：@Transactional(propagation = Propagation.NOT_SUPPORTED)或者@Rollback(false)。但务必小心！一定要在@AfterEach或@AfterAll方法中清理你产生的数据。可以使用JdbcTemplate执行清理SQL，或者使用像@Sql注解在测试后执行清理脚本。
• 最佳实践：尽量让每个测试方法独立，不依赖数据库的特定状态。使用TestEntityManager或Repository在@BeforeEach中插入测试所需的最小数据集，并依赖默认的回滚机制。对于只读的查询测试，可以加上@Transactional(readOnly = true)来提升性能并明确意图。

5.3 测试速度缓慢：上下文缓存与配置优化

问题：几百个测试跑下来要十几分钟，无法快速反馈。

优化策略：

1. 使用正确的切片测试注解：能用@WebMvcTest就别用@SpringBootTest，能用@DataJpaTest也别用@SpringBootTest。切片测试加载的Bean少得多，启动飞快。
2. 利用Spring的上下文缓存：Spring Test框架会缓存加载的应用上下文。只要测试类的配置（如@SpringBootTest的属性、@TestConfiguration、激活的Profile等）相同，上下文就只会加载一次。因此，将配置相似的测试类放在一起（或使用相同的父类）可以大幅提升速度。
3. 优化application-test.properties：关闭不必要的功能，比如management.endpoints.web.exposure.include=（关闭Actuator端点），spring.cloud.config.enabled=false（如果不用配置中心），spring.jpa.show-sql=false（关闭SQL日志，输出到控制台也很耗时）。
4. Mock外部依赖：对于调用外部HTTP API、消息队列、对象存储的服务，务必在集成测试中将其Mock掉（使用@MockBean或MockRestServiceServer）。启动一个WireMock服务器来模拟外部服务也是一种更接近真实的轻量级选择。
5. 并行执行测试：JUnit 5支持并行执行测试。在src/test/resources/junit-platform.properties中配置junit.jupiter.execution.parallel.enabled = true。但要注意，如果测试共享资源（如同一个H2内存数据库实例），可能会引发竞态条件，需要为每个测试类或方法配置独立的数据源。

5.4 脆弱的测试：避免过度指定与时机问题

问题：测试经常因为一些无关紧要的变化而失败，比如JSON字段顺序变了、Mock交互的精确次数不匹配等。

解决思路：

• 断言内容，而非格式：使用jsonPath(“$.id”)断言ID存在且有值，而不是断言整个JSON字符串完全匹配。使用assertThat(object).usingRecursiveComparison().isEqualTo(expectedObject)进行递归比较，忽略一些特定字段（如数据库生成的ID、创建时间）。
• 验证关键交互，而非所有交互：只verify那些有业务意义的、不调用就会出错的交互。避免验证内部工具方法的调用。
• 处理时间相关逻辑：测试中如果有new Date()或LocalDateTime.now()，结果每次都会变。解决方法是将时间作为参数传入，或者在测试中固定时钟（使用Clock.fixed()）。
• 异步测试：如果测试异步方法（如@Async,CompletableFuture），需要使用Awaitility库或JUnit 5的assertTimeout、assertTimeoutPreemptively来等待异步操作完成。

@Test void testAsyncOperation() { // 使用Awaitility await().atMost(5, TimeUnit.SECONDS) .untilAsserted(() -> assertThat(someAsyncResult).isEqualTo(expectedValue)); // 使用JUnit 5 assertTimeoutPreemptively(Duration.ofSeconds(5), () -> { // 调用异步方法并等待结果 SomeResult result = asyncService.method().get(); assertThat(result).isNotNull(); }); }

5.5 测试覆盖率与报告生成

写测试不是为了追求100%的覆盖率，但覆盖率是一个重要的参考指标，能帮你发现未被测试的代码块。Jacoco是Java生态中最常用的覆盖率工具。

Maven配置示例：

<plugin> <groupId>org.jacoco</groupId> <artifactId>jacoco-maven-plugin</artifactId> <version>0.8.11</version> <!-- 使用最新版本 --> <executions> <execution> <goals> <goal>prepare-agent</goal> </goals> </execution> <execution> <id>report</id> <phase>test</phase> <goals> <goal>report</goal> </goals> </execution> </executions> </plugin>

运行mvn clean test后，会在target/site/jacoco/目录下生成HTML报告。重点关注行覆盖率（Line Coverage）和分支覆盖率（Branch Coverage）。分支覆盖率往往更能揭示测试的完整性，比如一个if-else语句，你只测试了if为真的情况，行覆盖率可能是100%，但分支覆盖率只有50%。

解读报告：不要盲目追求数字。优先保证核心业务逻辑、复杂条件分支、异常处理路径的覆盖。工具类、简单的Getter/Setter、自动生成的代码（如Lombok的@Data）可以适当忽略。把覆盖率报告作为发现测试盲点的工具，而不是终极目标。

测试是保证微服务软件质量的基石，而JUnit和Mockito是构建这块基石的得力工具。从精准的单元测试到贴近真实的集成测试，每一层都有其明确的职责和最佳实践。记住，好的测试应该是快速、独立、可重复、自验证的。它不仅能捕获回归错误，更能作为代码的活文档，清晰地展示系统应该如何被使用。在微服务这个分布式、高复杂度的世界里，投资时间写好测试，就是在为你未来的开发效率和生产系统的稳定性购买一份最可靠的保险。