SpringBoot单元测试实战：JUnit5与Mockito构建高效测试体系

1. 项目概述：为什么我们需要一个坚实的单元测试体系？

如果你正在开发一个SpringBoot应用，无论是微服务还是单体应用，代码写到一定规模后，一个令人头疼的问题就会浮现：每次修改一个功能，哪怕只是改一行代码，你都得提心吊胆，生怕“牵一发而动全身”，把其他看似不相关的功能给搞坏了。手动启动应用、点点页面来测试？效率太低，而且覆盖不全。这时候，一个自动化、可重复、快速执行的单元测试体系，就成了保障代码质量的“生命线”。

单元测试，顾名思义，就是对软件中的最小可测试单元（在Java中通常是一个方法）进行检查和验证。它的目标不是发现所有bug，而是为你的代码建立一个快速反馈的安全网。想象一下，你重构了一个复杂的业务逻辑，改动了十几个方法，只需运行一下测试套件，几分钟内就能知道这次改动是否破坏了原有的功能。这种信心，是手动测试无法给予的。而JUnit5作为Java生态中最主流的测试框架，加上Mockito这个强大的模拟（Mock）框架，构成了构建这套安全网的黄金组合。SpringBoot Test则提供了与Spring容器无缝集成的能力，让测试Spring Bean变得轻而易举。

本文的目标，就是带你从零开始，为一个典型的SpringBoot应用搭建一套完整、规范、高效的单元测试体系。我不会只讲“是什么”，而会重点分享“为什么”要这么设计，以及在实际项目中“怎么做”才能避免踩坑。无论你是刚接触测试的新手，还是想优化现有测试套件的开发者，都能从中找到可以直接“抄作业”的实践方案。

2. 测试体系整体设计与核心思路

在动手写第一行测试代码之前，理清整体设计思路至关重要。一个混乱的测试套件，其维护成本可能比它要保护的业务代码还高。我们的核心思路是：分层测试、关注行为、隔离依赖。

2.1 测试金字塔与我们的策略

经典的测试金字塔将测试分为三层：单元测试（多）、集成测试（中）、端到端测试（少）。我们的重点是最底层的单元测试。对于SpringBoot应用，单元测试主要针对两类对象：

1. 纯业务逻辑类：例如Service层的核心算法、工具类、校验器等。这类测试应尽可能脱离Spring容器，运行速度极快。
2. Spring管理的Bean：例如Service、Controller、Repository（或Mapper）。这类测试需要Spring容器的支持来注入依赖。

我们的策略是：能不用Spring容器就不用。对于Service的测试，如果其依赖的其他Bean可以被轻松模拟（Mock），那么就使用Mockito进行模拟，让测试在纯Java环境下运行。只有在测试涉及多个Bean交互、事务管理或需要真实数据库交互（这其实已偏向集成测试）时，才启用Spring容器。这样能最大化测试的执行速度。

2.2 工具选型与版本考量

• JUnit 5 (Jupiter): 这是我们的测试框架基石。相比JUnit 4，JUnit 5提供了更丰富的扩展模型（Extension API）、更灵活的标签（Tag）过滤、参数化测试等强大功能。spring-boot-starter-test默认就包含了JUnit 5。
• Mockito: 用于创建和配置模拟对象（Mock）。当测试一个UserService时，它依赖的UserRepository就可以被Mock，这样我们就能专注于UserService自身的逻辑，而无需关心数据库的真实状态。Mockito的@Mock、@InjectMocks、@Spy等注解能极大简化测试代码。
• Spring Boot Test: 提供了一系列注解和工具类来支持Spring应用的测试。核心是@SpringBootTest，它会启动一个完整的或接近完整的应用上下文。但我们要谨慎使用它，因为它启动较慢。
• AssertJ: 一个流式断言库，比JUnit自带的Assertions更强大、表达力更强。它的链式调用让断言代码读起来像自然语言，例如assertThat(user).isNotNull().hasFieldOrPropertyWithValue("name", "张三")。
• JSONassert / Hamcrest: 用于复杂对象或JSON结构的比较，可以根据需要引入。

注意：spring-boot-starter-test已经为我们整合了JUnit 5, Mockito, AssertJ, Hamcrest等库，通常我们只需要引入这一个依赖即可。但理解每个组件的作用，有助于我们在遇到问题时进行排查和深度定制。

2.3 测试代码结构规范

清晰的代码结构是可持续维护的基础。我推荐遵循Maven/Gradle的标准目录布局，并与生产代码保持平行结构。

src/ ├── main/ │ ├── java/com/yourcompany/yourapp/ │ │ ├── controller/ │ │ ├── service/ │ │ └── repository/ │ └── resources/ └── test/ ├── java/com/yourcompany/yourapp/ │ ├── controller/ // 可选，通常测试Controller更偏向集成测试 │ ├── service/ │ │ ├── UserServiceTest.java │ │ └── impl/ // 如果有实现类 │ ├── repository/ // 这里可能是集成测试，需要连接真实数据库或嵌入式数据库 │ └── utils/ // 工具类测试 └── resources/ └── application-test.properties // 测试专用配置文件

测试类的命名通常为被测试类名+Test，例如UserServiceTest。测试方法的命名应描述其行为，我习惯用方法名_测试场景_期望结果的格式，例如createUser_WhenEmailIsDuplicate_ShouldThrowException。虽然看起来长，但可读性极佳，无需额外注释。

3. 核心细节解析与Mockito实战技巧

这一节我们深入核心，看看如何用JUnit 5和Mockito编写高质量的单元测试。我会分享很多官方文档里不会写的“实战技巧”。

3.1 JUnit 5基础：超越@Test

JUnit 5的注解更加丰富和清晰。

• @Test: 标记一个测试方法。
• @BeforeEach/@AfterEach: 在每个测试方法之前/之后运行。常用于初始化测试数据或清理资源。注意：每个测试方法都会运行一次，确保测试之间的隔离。
• @BeforeAll/@AfterAll: 在所有测试方法之前/之后运行一次。方法必须是static。适合初始化昂贵且共享的资源，如数据库连接池（但单元测试应尽量避免）。
• @DisplayName: 为测试类或方法设置一个易读的名称，会在测试报告中显示。
• @Disabled: 临时禁用某个测试。

一个常见的误区：在@BeforeEach中初始化被测试对象（如Service）和它的Mock依赖。这没问题，但要小心测试间的状态污染。确保每个测试都是独立的。

3.2 Mockito核心：模拟、存根与验证

Mockito的核心功能有三：创建模拟对象（Mock）、定义模拟对象的行为（Stubbing）、验证模拟对象的交互（Verification）。

1. 创建Mock对象

// 方式1：使用注解（需要搭配 @ExtendWith(MockitoExtension.class)） @ExtendWith(MockitoExtension.class) class UserServiceTest { @Mock private UserRepository userRepository; // 将被模拟的依赖 @InjectMocks private UserService userService; // 被测试对象，Mock会自动注入 } // 方式2：编程式创建 UserRepository mockRepo = Mockito.mock(UserRepository.class); UserService service = new UserService(mockRepo);

推荐使用注解方式，更简洁。@InjectMocks会尝试通过构造函数、setter或字段注入的方式，将@Mock（或@Spy）标注的依赖注入到被测试对象中。

2. 定义行为（Stubbing）这是Mockito的灵魂。当调用Mock对象的方法时，你可以指定它返回什么值或抛出什么异常。

// 当调用 userRepository.findByEmail("test@example.com") 时，返回一个预设的User对象 User expectedUser = new User(1L, "test@example.com"); when(userRepository.findByEmail("test@example.com")).thenReturn(expectedUser); // 当调用 userRepository.findByEmail("notexist@example.com") 时，返回 null when(userRepository.findByEmail("notexist@example.com")).thenReturn(null); // 当调用 userRepository.save(any(User.class)) 时，返回传入的参数（模拟保存操作） when(userRepository.save(any(User.class))).thenAnswer(invocation -> invocation.getArgument(0)); // 当调用某个void方法时，让它抛出异常 doThrow(new RuntimeException("DB error")).when(userRepository).deleteById(1L);

关键技巧：使用any(),eq(),isNull()等参数匹配器，可以让Stubbing更灵活。但要注意，一旦使用了参数匹配器，所有参数都必须使用匹配器。

3. 验证交互（Verification）测试不仅要验证结果（状态验证），有时还需要验证对象之间的协作（行为验证）。

// 验证 userRepository.save() 方法被调用了一次，并且传入的参数是某个特定的user对象 verify(userRepository, times(1)).save(expectedUser); // 验证 userRepository.deleteById() 方法从未被调用过 verify(userRepository, never()).deleteById(anyLong()); // 验证在某个Mock对象上，除了指定的交互，没有其他更多交互 verifyNoMoreInteractions(userRepository); // 使用需谨慎，有时会过于严格

实操心得：不要过度使用行为验证。单元测试应更关注被测方法的输出结果（状态），而非其内部实现细节（行为）。过度验证行为会导致测试变得脆弱，一旦内部实现重构（比如调用了另一个方法），即使功能正确测试也会失败。行为验证更适合验证“是否发送了消息”、“是否调用了关键的外部服务”等有副作用的操作。

3.3 断言的艺术：使用AssertJ

JUnit 5自带的断言够用，但AssertJ更强大。

import static org.assertj.core.api.Assertions.*; // 基本对象断言 assertThat(actualUser).isNotNull(); assertThat(actualUser.getId()).isEqualTo(1L); assertThat(actualUser.getName()).contains("张"); // 集合断言 assertThat(userList).hasSize(3) .extracting(User::getName) // 提取属性 .containsExactlyInAnyOrder("张三", "李四", "王五"); // 顺序无关，包含所有 // 异常断言 assertThatThrownBy(() -> userService.createUser(null)) .isInstanceOf(IllegalArgumentException.class) .hasMessage("用户不能为空"); // 链式断言，可读性极高 assertThat(actualUser) .isNotNull() .hasFieldOrPropertyWithValue("email", "test@example.com") .extracting(User::getProfile) .isNotNull();

AssertJ的错误信息也远比原生断言友好，能直接告诉你期望值和实际值的差异。

4. 分层测试实战：Service、Controller与Repository

现在，我们针对SpringBoot应用的不同层，看看具体的测试写法。

4.1 Service层测试：Mock的典型战场

Service层包含核心业务逻辑，是单元测试的重点。我们目标是让测试快速运行，所以会大量使用Mock。

@ExtendWith(MockitoExtension.class) // 使用Mockito扩展，无需启动Spring class UserServiceTest { @Mock private UserRepository userRepository; @Mock private EmailService emailService; // 另一个依赖，比如发邮件的服务 @InjectMocks private UserServiceImpl userService; // 注入Mock @Test @DisplayName("创建用户-成功场景") void createUser_WhenDataIsValid_ShouldSuccessAndSendEmail() { // 1. 准备测试数据 (Arrange) UserCreateRequest request = new UserCreateRequest("张三", "zhangsan@example.com"); User savedUser = new User(1L, "张三", "zhangsan@example.com"); // 2. 定义Mock行为 (Stubbing) when(userRepository.findByEmail(request.getEmail())).thenReturn(null); // 模拟邮箱不存在 when(userRepository.save(any(User.class))).thenReturn(savedUser); // 模拟保存成功 doNothing().when(emailService).sendWelcomeEmail(anyString()); // 模拟发邮件，无返回值 // 3. 执行被测方法 (Act) User result = userService.createUser(request); // 4. 验证结果和交互 (Assert) assertThat(result).isNotNull(); assertThat(result.getId()).isEqualTo(1L); assertThat(result.getEmail()).isEqualTo(request.getEmail()); // 验证必要的交互：保存被调用一次，欢迎邮件被发送一次 verify(userRepository).save(any(User.class)); verify(emailService).sendWelcomeEmail(savedUser.getEmail()); } @Test @DisplayName("创建用户-邮箱已存在") void createUser_WhenEmailExists_ShouldThrowException() { UserCreateRequest request = new UserCreateRequest("张三", "exist@example.com"); User existingUser = new User(99L, "老用户", "exist@example.com"); when(userRepository.findByEmail(request.getEmail())).thenReturn(existingUser); // 使用AssertJ断言异常 assertThatThrownBy(() -> userService.createUser(request)) .isInstanceOf(BusinessException.class) .hasMessageContaining("邮箱已注册"); // 验证当异常抛出时，save方法没有被调用 verify(userRepository, never()).save(any()); } }

注意事项：

• 每个测试方法应只测试一个场景。上面的例子中，一个测试成功流程，一个测试异常流程。
• when().thenReturn()用于模拟有返回值的方法。doNothing().when()用于模拟无返回值（void）的方法。
• 在验证交互时，verify的调用次数默认是times(1)，可以省略。

4.2 Controller层测试：使用@WebMvcTest

Controller测试通常更偏向集成测试，因为它涉及HTTP请求和响应的处理、序列化/反序列化、过滤器、拦截器等。Spring Boot提供了@WebMvcTest注解，它可以只启动Web层相关的上下文，比@SpringBootTest轻量得多。

@WebMvcTest(UserController.class) // 只加载UserController及其相关配置（如Jackson） @AutoConfigureMockMvc // 自动配置MockMvc class UserControllerTest { @Autowired private MockMvc mockMvc; // 模拟HTTP请求的核心类 @MockBean // 注意这里是@MockBean，不是@Mock。它会将Mock放入Spring上下文。 private UserService userService; @Test @DisplayName("GET /users/{id} - 成功返回用户") void getUserById_ShouldReturnUser() throws Exception { Long userId = 1L; User mockUser = new User(userId, "张三", "zhangsan@example.com"); when(userService.getUserById(userId)).thenReturn(mockUser); mockMvc.perform(get("/api/users/{id}", userId) // 发起GET请求 .accept(MediaType.APPLICATION_JSON)) .andExpect(status().isOk()) // 断言HTTP状态码为200 .andExpect(jsonPath("$.id").value(userId)) // 使用JsonPath断言JSON响应体 .andExpect(jsonPath("$.name").value("张三")) .andDo(print()); // 打印请求和响应详情，调试时非常有用 } @Test @DisplayName("POST /users - 成功创建用户") void createUser_ShouldReturnCreated() throws Exception { UserCreateRequest request = new UserCreateRequest("李四", "lisi@example.com"); User createdUser = new User(2L, "李四", "lisi@example.com"); when(userService.createUser(any(UserCreateRequest.class))).thenReturn(createdUser); // 使用ObjectMapper将对象转为JSON字符串 ObjectMapper objectMapper = new ObjectMapper(); String requestBody = objectMapper.writeValueAsString(request); mockMvc.perform(post("/api/users") .contentType(MediaType.APPLICATION_JSON) .content(requestBody)) .andExpect(status().isCreated()) .andExpect(header().string("Location", containsString("/users/2"))) .andExpect(jsonPath("$.id").value(2L)); } }

关键点解析：

• @WebMvcTest会配置Spring MVC基础设施，但不会加载完整的应用上下文（如Service、Repository的Bean，除非用@MockBean模拟）。
• MockMvc是模拟HTTP请求的利器，可以模拟各种HTTP方法、头信息、请求体。
• @MockBean是Spring Boot Test提供的注解，用于在Spring应用上下文中添加一个Mockito Mock。这样，Controller中@Autowired的UserService就会被替换成这个Mock。
• jsonPath是一个强大的DSL，用于从JSON响应体中提取和断言值。语法类似于XPath，学习成本很低。

4.3 Repository层测试：与真实数据库交互

Repository（或MyBatis的Mapper）的测试，严格来说属于集成测试，因为它需要与真实的数据库交互。我们的目标是测试SQL语句或JPA映射的正确性，而不是数据库本身。 为了快速和隔离，我们使用嵌入式数据库，如H2。

首先，在src/test/resources/application-test.properties中配置测试专用的数据源：

spring.datasource.url=jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1;MODE=MYSQL spring.datasource.driver-class-name=org.h2.Driver spring.datasource.username=sa spring.datasource.password= spring.jpa.database-platform=org.hibernate.dialect.H2Dialect spring.sql.init.platform=h2 # 可选：初始化测试数据 spring.sql.init.schema-locations=classpath:schema-test.sql spring.sql.init.data-locations=classpath:data-test.sql

然后，编写Repository测试：

@DataJpaTest // 关键注解！只加载JPA相关的配置，使用嵌入式数据库，自动回滚事务。 @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE) // 如果已配置H2，此注解可省略或用于指定不替换 class UserRepositoryTest { @Autowired private TestEntityManager entityManager; // JPA测试工具，用于持久化实体到测试数据库 @Autowired private UserRepository userRepository; @Test @DisplayName("根据邮箱查找用户") void findByEmail_ShouldReturnUser() { // 使用TestEntityManager准备数据，不经过Repository，更底层 User savedUser = entityManager.persistAndFlush(new User(null, "王五", "wangwu@example.com")); // 执行查询 Optional<User> found = userRepository.findByEmail("wangwu@example.com"); // 验证 assertThat(found).isPresent(); assertThat(found.get().getName()).isEqualTo("王五"); assertThat(found.get().getId()).isEqualTo(savedUser.getId()); } @Test @DisplayName("查找不存在的邮箱返回空") void findByEmail_WhenNotExist_ShouldReturnEmpty() { Optional<User> found = userRepository.findByEmail("nonexist@example.com"); assertThat(found).isEmpty(); } }

@DataJpaTest的魔法：

1. 它配置了一个嵌入式的H2数据库（如果classpath下有）。
2. 它扫描@Entity类并配置Spring Data JPA仓库。
3. 默认情况下，每个测试方法都在一个事务中执行，并在方法结束后自动回滚。这确保了测试之间的完全隔离，不会污染数据库。
4. 它自动注入TestEntityManager，这是一个用于测试的JPA实体管理器。

踩坑记录：如果你在测试中使用了@Transactional，并且测试方法调用了被@Async注解的异步方法，由于事务传播的特性，异步方法可能在新线程中执行，无法看到主线程未提交的数据，导致测试失败。这时可能需要调整事务管理策略，或者使用TransactionTemplate手动控制。

5. 高级主题与测试优化策略

当测试套件逐渐庞大，你会遇到一些更复杂的需求和挑战。

5.1 参数化测试：用一组数据测试同一个逻辑

如果一个方法的行为依赖于不同的输入，为每个输入写一个测试方法很冗余。JUnit 5的参数化测试可以解决这个问题。

@ParameterizedTest // 标记为参数化测试 @CsvSource({ "1, '张三', true", // 用户存在且活跃 "2, '李四', false", // 用户存在但不活跃 "999, '', false" // 用户不存在 }) @DisplayName("根据ID检查用户是否活跃") void checkUserActive_WithDifferentIds_ShouldReturnExpected(Long userId, String expectedName, boolean expectedActive) { // 根据参数动态定义Mock行为 User mockUser = null; if (userId == 1L) { mockUser = new User(userId, "张三", true); } else if (userId == 2L) { mockUser = new User(userId, "李四", false); } when(userRepository.findById(userId)).thenReturn(Optional.ofNullable(mockUser)); UserStatus status = userService.checkUserStatus(userId); assertThat(status.isActive()).isEqualTo(expectedActive); if (expectedName != null && !expectedName.isEmpty()) { assertThat(status.getUserName()).isEqualTo(expectedName); } else { assertThat(status.getUserName()).isNull(); } }

除了@CsvSource，还有@ValueSource（基本类型）、@MethodSource（从指定方法获取参数）等来源，非常灵活。

5.2 测试私有方法？慎重！

一个经典争议：要不要测试私有方法？我的观点是：优先通过公有方法测试私有方法的行为。私有方法是实现细节，测试应该关注公有契约（即类的公开方法对外表现出的行为）。如果你发现一个私有方法复杂到需要单独测试，这通常是一个信号：这个私有方法应该被提取到一个独立的、可公开测试的类中（比如一个工具类或策略类）。这遵循了“单一职责原则”。

如果由于历史原因或特殊情况必须测试私有方法，可以使用反射，但这会让测试变得脆弱。Spring提供了ReflectionTestUtils工具类来简化操作，但这应是最后的手段。

5.3 集成测试：@SpringBootTest的合理使用

当你需要测试多个Bean的交互、事务传播、或者整个应用上下文的启动过程时，就需要用到@SpringBootTest。它会加载完整的应用上下文，速度较慢。

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) // 启动一个真实的嵌入式Servlet容器（如Tomcat），并随机分配端口 @AutoConfigureMockMvc // @Transactional // 同样可以加事务实现自动回滚 class UserIntegrationTest { @Autowired private MockMvc mockMvc; @Autowired private UserRepository userRepository; // 这次是真实的Repository @Test void createUserThroughAllLayers() throws Exception { UserCreateRequest request = new UserCreateRequest("集成测试用户", "integration@test.com"); mockMvc.perform(post("/api/users") .contentType(MediaType.APPLICATION_JSON) .content(new ObjectMapper().writeValueAsString(request))) .andExpect(status().isCreated()); // 验证数据是否真的落到了（测试）数据库 Optional<User> savedUser = userRepository.findByEmail("integration@test.com"); assertThat(savedUser).isPresent(); assertThat(savedUser.get().getName()).isEqualTo("集成测试用户"); } }

关键决策：使用WebEnvironment.MOCK（默认，不启动Servlet容器）还是RANDOM_PORT/DEFINED_PORT（启动真实容器）？如果测试只涉及MVC层，用@WebMvcTest。如果测试需要完整的HTTP栈（如过滤器、Servlet、SSL），就用RANDOM_PORT。

5.4 测试配置与环境隔离

务必为测试创建独立的配置文件application-test.properties或application-test.yml。通过@ActiveProfiles("test")注解激活它。这可以让你：

• 使用嵌入式数据库（H2）。
• 禁用外部服务的调用（如邮件、短信、支付），或者将其指向Mock服务器（如WireMock）。
• 调整日志级别，避免测试时输出过多日志干扰。
• 关闭一些生产环境才需要的特性，如缓存预热、定时任务。

6. 常见问题、排查技巧与持续集成

即使按照最佳实践编写，测试过程中也会遇到各种问题。这里记录一些高频问题和解决思路。

6.1 依赖注入失败：@Autowired字段为null

这是新手最常见的问题。

• 检查测试类注解：如果你用了@Mock和@InjectMocks，必须加上@ExtendWith(MockitoExtension.class)。如果你用了Spring的注解（如@SpringBootTest,@WebMvcTest），则不需要（也不能）加Mockito的扩展，而应该用@MockBean。
• 检查包扫描：确保你的测试类所在的包在Spring主应用类（@SpringBootApplication标注的类）的包或其子包下，否则Spring可能扫描不到你的配置。或者，在@SpringBootTest中显式指定主类：@SpringBootTest(classes = YourApplication.class)。
• 检查依赖范围：确保spring-boot-starter-test的依赖在test作用域内。

6.2 Mock行为不生效

• Stubbing时机：必须在调用被测方法之前定义Mock行为。通常放在@BeforeEach或测试方法开头。
• 参数匹配问题：when(mock.someMethod(eq("foo"))).thenReturn(...)和when(mock.someMethod("foo")).thenReturn(...)在大多数情况下等价。但如果你用了any()等匹配器，则该次调用中的所有参数都必须使用匹配器。when(mock.someMethod(any(), "fixed")).thenReturn(...)是合法的，而when(mock.someMethod(any(), eq("fixed")))也是合法的，但when(mock.someMethod(any(), "fixed"))在某些旧版本可能导致问题，建议统一使用eq()包装字面值。
• 过度Stubbing：如果你为一个Mock对象定义了行为，但测试中并未调用该方法，Mockito默认是允许的。但你可以通过Mockito.lenient()来标记非严格的Stubbing，或者使用@Mock(strictness = Mock.Strictness.LENIENT)注解。更推荐的做法是，使用verify来确认预期的交互发生了，并清理掉无用的Stubbing。

6.3 事务与数据回滚问题

• @DataJpaTest和@SpringBootTest默认会回滚：这是好事。但如果你在测试中手动获取了数据库连接（如用JdbcTemplate）执行了操作，这些操作可能不在Spring管理的事务内，导致不会自动回滚。确保这些操作也在@Transactional方法内执行。
• 需要测试不回滚的场景：有时你想测试一个真实提交的事务。可以在测试方法或类上加上@Transactional(propagation = Propagation.NOT_SUPPORTED)来禁用事务，但记得在@AfterEach中手动清理数据，否则会影响其他测试。
• 异步方法：如前所述，@Async方法在新线程运行，默认无法加入当前测试事务。测试这类方法时，可能需要使用@Transactional(propagation = Propagation.REQUIRES_NEW)或者将异步改为同步进行测试（通过@SpringBootTest的属性或配置类覆盖@Async的生效条件）。

6.4 测试速度优化

当你有上千个测试时，速度就是生命。

1. 分层：严格区分单元测试（无Spring）、切片测试（如@WebMvcTest,@DataJpaTest）、集成测试（@SpringBootTest）。在CI流水线中，可以优先快速运行单元测试，再运行较慢的集成测试。
2. 避免不必要的@SpringBootTest：问问自己，这个测试真的需要启动整个Spring容器吗？
3. 使用测试标签：JUnit 5的@Tag注解可以给测试分类。你可以在Maven/Gradle中配置只运行某个标签的测试。例如，给慢速的集成测试打上@Tag("integration")，在本地开发时跳过它们。

   <!-- Maven 配置 --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <groups>unit</groups> <!-- 默认只运行unit标签的测试 --> </configuration> </plugin>

4. Mock外部服务：任何HTTP调用、消息队列、文件IO都应该是Mock的对象。可以使用WireMock来模拟HTTP API。

6.5 集成到CI/CD流水线

一个健康的项目，应该将测试作为持续集成（CI）的强制关卡。

• Maven:mvn clean test会运行所有src/test/java下的测试。可以使用-DskipTests跳过，但CI上绝不建议。
• Gradle:gradle clean test。
• 生成测试报告：Surefire插件会生成XML和HTML格式的报告。可以与Jenkins、GitLab CI、GitHub Actions等集成，可视化展示测试结果和趋势。
• 代码覆盖率：使用JaCoCo等工具收集覆盖率报告。我个人的经验是，不要盲目追求高覆盖率（比如95%以上），而应关注关键业务逻辑和复杂代码的覆盖率。覆盖率只是一个参考指标，更重要的是测试用例设计的质量。在CI中集成覆盖率检查，可以设置一个合理的下限（如核心模块80%），防止代码质量滑坡。

构建一个健壮的单元测试体系不是一蹴而就的，它需要像编写业务代码一样被精心设计和维护。从为一个简单的Service方法编写第一个测试开始，逐步建立规范，积累工具和技巧，你会发现它带来的代码信心和重构勇气，远超过最初的投入。当团队养成“测试驱动开发”或至少是“测试伴随开发”的习惯后，整个项目的可维护性和交付质量都会有质的提升。