SpringBoot项目实战JUnit5单元测试从入门到精通附完整代码示例如果你已经用SpringBoot开发过几个项目可能会发现一个现象项目初期业务逻辑清晰代码跑得飞快但随着功能迭代每次修改代码都变得小心翼翼生怕一个不小心就破坏了某个隐藏的功能点。这种“如履薄冰”的开发体验很大程度上源于我们对代码行为的“不确定性”。单元测试特别是与SpringBoot深度集成的JUnit5测试正是消除这种不确定性的利器。它不是一项可有可无的“面子工程”而是保障现代软件工程交付质量、提升开发效率的核心实践。本文将带你从零开始在SpringBoot项目中搭建、编写并优化JUnit5单元测试通过大量贴近实战的代码示例让你不仅“会用”更能“精通”最终打造出健壮、可维护的高质量代码。1. 环境搭建与基础配置为SpringBoot测试铺平道路开始编写测试之前一个正确且高效的测试环境是基石。对于SpringBoot项目我们通常使用Maven或Gradle进行依赖管理。JUnit5的依赖配置与JUnit4有显著不同理解其模块化设计是第一步。JUnit5由三个主要子项目组成JUnit Platform 作为在JVM上启动测试框架的基础它定义了TestEngineAPI用于开发在平台上运行的测试框架。同时它还提供了从命令行、Gradle和Maven运行测试的控制台启动器。JUnit Jupiter 这是编写测试和扩展的新编程模型。我们日常使用的Test、BeforeEach等注解都来自这个模块。它还为平台提供了一个TestEngine来运行Jupiter测试。JUnit Vintage 提供了一个TestEngine用于在JUnit5平台上运行JUnit 3或JUnit 4编写的测试。这对于老项目迁移至关重要。在典型的SpringBoot 2.x或3.x项目中我们通常不需要单独声明这些依赖。Spring Boot的spring-boot-starter-test起步依赖已经为我们整合了JUnit Jupiter、Mockito、AssertJ、Hamcrest等一整套测试工具链。下面是一个标准的Maven配置dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-test/artifactId scopetest/scope /dependency注意spring-boot-starter-test默认排除了JUnit 4junit:junit并引入了JUnit Jupiter。如果你的项目中有遗留的JUnit 4测试需要显式引入junit-vintage-engine否则这些测试将无法运行。仅仅引入依赖还不够一个高效的测试类结构同样重要。我习惯在src/test/java下建立与主代码相同的包结构这样能清晰地建立测试与被测试类的对应关系。IDEA和Eclipse等现代IDE对JUnit5的支持已经非常完善你可以通过快捷键如IDEA的CtrlShiftT快速为某个类生成测试骨架。为了让测试运行得更快特别是当测试不需要启动完整的Spring应用上下文时例如纯业务逻辑的单元测试我们可以利用JUnit5的TestInstance注解和Spring的SpringBootTest注解的巧妙组合。默认情况下JUnit Jupiter为每个测试方法创建一个新的测试类实例这可能会带来一些开销。我们可以将其改为每类生命周期import org.junit.jupiter.api.TestInstance; TestInstance(TestInstance.Lifecycle.PER_CLASS) SpringBootTest class MyServiceTest { // 现在BeforeAll和AfterAll方法可以声明为非静态的 BeforeAll void initAll() { // 初始化操作只执行一次 } }这个设置对于需要昂贵初始化操作的测试如建立数据库连接池特别有用可以显著提升测试套件的执行速度。2. JUnit5核心注解在SpringBoot中的实战应用JUnit5提供了一套丰富且强大的注解用于控制测试的生命周期和行为。在SpringBoot环境中这些注解与Spring的测试注解如MockBean、SpyBean结合使用能发挥出巨大威力。让我们抛开枯燥的列表通过一个用户服务UserService的测试案例来深入理解。假设我们有一个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.existsByUsername(username)) { throw new IllegalArgumentException(用户名已存在); } User newUser new User(username, email); User savedUser userRepository.save(newUser); emailService.sendWelcomeEmail(email); // 发送欢迎邮件 return savedUser; } }现在我们来为其编写测试。首先是测试类的骨架和生命周期方法import org.junit.jupiter.api.*; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.boot.test.context.SpringBootTest; import org.springframework.boot.test.mock.mockito.MockBean; SpringBootTest // 标记为SpringBoot测试会加载应用上下文 TestInstance(TestInstance.Lifecycle.PER_CLASS) // 使用类级别生命周期 DisplayName(用户服务单元测试套件) class UserServiceTest { Autowired private UserService userService; // 注入真实的待测试服务 MockBean private UserRepository userRepositoryMock; // 模拟Repository避免真实数据库操作 MockBean private EmailService emailServiceMock; // 模拟邮件服务 BeforeAll void globalSetUp() { // 整个测试类开始前执行一次适合做全局配置 System.out.println( 开始执行UserService测试套件); } AfterAll void globalTearDown() { // 整个测试类结束后执行一次 System.out.println( UserService测试套件执行完毕); } BeforeEach void setUp(TestInfo testInfo) { // 每个Test方法执行前都会运行 // TestInfo参数可以让我们知道即将运行的是哪个测试 System.out.println(准备执行测试: testInfo.getDisplayName()); // 重置Mock对象的状态避免测试间相互影响 Mockito.reset(userRepositoryMock, emailServiceMock); } AfterEach void tearDown() { // 每个Test方法执行后都会运行适合清理资源 System.out.println(测试执行完毕进行清理...); } }接下来我们编写第一个真正的测试方法测试用户注册的成功场景Test DisplayName(注册新用户 - 成功案例) // 为测试方法起一个可读性高的名字 void registerUser_Success() { // 1. 准备测试数据 (Given) String username testUser; String email testexample.com; User mockUser new User(username, email); mockUser.setId(1L); // 2. 定义Mock对象的行为 (When) // 当检查用户名是否存在时返回false表示用户名可用 when(userRepositoryMock.existsByUsername(username)).thenReturn(false); // 当保存用户时返回我们模拟的用户对象 when(userRepositoryMock.save(any(User.class))).thenReturn(mockUser); // 对于void方法通常只需验证其被调用这里先不做任何设置 // 3. 执行待测试的方法 (Then - Act) User result userService.registerUser(username, email); // 4. 验证结果和行为 (Then - Assert) // 验证返回的用户不为空 assertNotNull(result, 返回的用户对象不应为空); // 验证返回的用户ID正确 assertEquals(1L, result.getId(), 用户ID应该为1); // 验证用户名和邮箱正确 assertEquals(username, result.getUsername(), 用户名不一致); assertEquals(email, result.getEmail(), 邮箱不一致); // 验证依赖的交互行为 // 验证userRepositoryMock.existsByUsername被以正确的参数调用了一次 verify(userRepositoryMock, times(1)).existsByUsername(username); // 验证userRepositoryMock.save被调用了一次 verify(userRepositoryMock, times(1)).save(any(User.class)); // 验证emailServiceMock.sendWelcomeEmail被以正确的邮箱参数调用了一次 verify(emailServiceMock, times(1)).sendWelcomeEmail(email); }这个测试展示了典型的“Given-When-Then”模式并混合使用了JUnit5的断言assertNotNull,assertEquals和Mockito的验证verify。DisplayName注解让测试报告的可读性大大提升。现在让我们看一个失败场景的测试验证当用户名已存在时是否会抛出预期的异常Test DisplayName(注册新用户 - 用户名已存在应抛出异常) void registerUser_UsernameExists_ThrowsException() { // Given String existingUsername existingUser; String email userexample.com; // 模拟用户名已存在 when(userRepositoryMock.existsByUsername(existingUsername)).thenReturn(true); // When Then // 使用assertThrows来断言会抛出特定异常 IllegalArgumentException exception assertThrows( IllegalArgumentException.class, () - userService.registerUser(existingUsername, email), 当用户名已存在时应抛出IllegalArgumentException ); // 还可以进一步断言异常信息 assertTrue(exception.getMessage().contains(用户名已存在)); // 验证在抛出异常后save方法和sendWelcomeEmail方法没有被调用 verify(userRepositoryMock, never()).save(any(User.class)); verify(emailServiceMock, never()).sendWelcomeEmail(anyString()); }assertThrows是JUnit5中一个非常实用的断言它接收一个异常类型和一个可执行代码块如果代码块抛出了指定类型或其子类的异常则断言成功并返回该异常对象供进一步检查。除了这些基础注解JUnit5还提供了更高级的测试组织方式比如Nested嵌套测试类。它允许我们以内部类的形式对测试进行逻辑分组每个嵌套类都可以有自己的BeforeEach和AfterEach方法非常适合按功能或状态对测试进行分层。Nested DisplayName(用户查询相关测试) class FindUserTests { Test DisplayName(根据ID查找用户 - 用户存在) void findById_UserExists() { // ... 测试查找存在的用户 } Test DisplayName(根据ID查找用户 - 用户不存在) void findById_UserNotExists() { // ... 测试查找不存在的用户可能返回Optional.empty() } }3. 超越基础断言使用AssertJ编写流畅断言虽然JUnit5自带的Assertions类功能齐全但在编写复杂断言时代码可能显得冗长且不易读。AssertJ库提供了流式断言Fluent AssertionsAPI能让你的测试断言像说句子一样流畅自然极大地提升了测试代码的可读性和编写体验。首先确保你的spring-boot-starter-test依赖已经包含了AssertJ默认包含。然后在测试类中静态导入Assertions.assertThat方法import static org.assertj.core.api.Assertions.assertThat;让我们用AssertJ重写前面成功注册测试中的断言部分Test DisplayName(使用AssertJ断言注册新用户 - 成功案例) void registerUser_Success_WithAssertJ() { // ... Given When 部分与之前相同 when(userRepositoryMock.existsByUsername(username)).thenReturn(false); when(userRepositoryMock.save(any(User.class))).thenReturn(mockUser); User result userService.registerUser(username, email); // 使用AssertJ进行断言 assertThat(result) // 断言对象 .isNotNull() // 不为空 .extracting(User::getId, User::getUsername, User::getEmail) // 提取多个属性 .containsExactly(1L, username, email); // 精确匹配提取的值列表 // 针对集合或字符串的断言示例假设User有一个getRoles方法返回List // assertThat(result.getRoles()).isNotEmpty().contains(USER); // assertThat(result.getEmail()).contains().endsWith(example.com); }AssertJ的强大之处在于其丰富的断言方法和链式调用。下面这个表格对比了JUnit5断言和AssertJ在常见场景下的写法断言场景JUnit5 写法AssertJ 流式写法可读性对比对象非空且属性匹配assertNotNull(result);assertEquals(name, result.getName());assertThat(result).isNotNull().extracting(User::getName).isEqualTo(name);AssertJ更连贯像一句话集合包含元素assertTrue(list.contains(item));assertThat(list).contains(item);AssertJ意图更明确检查异常消息assertEquals(错误消息, exception.getMessage());assertThat(exception).hasMessage(错误消息);AssertJ直接针对异常对象数字范围检查assertTrue(age 18 age 65);assertThat(age).isBetween(19, 64);AssertJ更简洁直观字符串匹配assertTrue(email.endsWith(.com));assertThat(email).endsWith(.com);AssertJ更优雅AssertJ还支持软断言Soft Assertions允许在一次测试中收集多个断言失败而不是在第一个失败时就停止。这在需要验证对象多个属性的场景下非常有用。Test DisplayName(使用软断言验证用户对象多个属性) void testUserWithSoftAssertions() { User user userService.findUserById(1L); // 假设这个方法存在 SoftAssertions softly new SoftAssertions(); softly.assertThat(user.getId()).isEqualTo(1L); softly.assertThat(user.getUsername()).isNotBlank(); softly.assertThat(user.getEmail()).contains(); softly.assertThat(user.getStatus()).isEqualTo(ACTIVE); softly.assertAll(); // 在此处统一报告所有断言失败 }4. 模拟与依赖隔离使用Mockito进行高效单元测试单元测试的核心思想是隔离。我们希望测试UserService时不依赖于真实的UserRepository和EmailService因为它们可能涉及数据库操作、网络调用等不稳定或缓慢的外部依赖。Mockito是Java生态中最流行的模拟框架Spring Boot Test已经自动集成了它。我们已经在前面的例子中使用了MockBean注解。它是Spring Boot特有的用于在Spring的ApplicationContext中为一个bean添加Mockito mock。与之对应的是Mock注解它是纯Mockito的用于在非Spring上下文中创建模拟对象。在SpringBoot集成测试中MockBean是首选。4.1 模拟对象的行为配置Mockito的核心功能之一是打桩Stubbing即定义模拟对象在接收到特定调用时应返回什么值或执行什么动作。// 1. 返回固定值 when(userRepositoryMock.findById(1L)).thenReturn(Optional.of(mockUser)); // 2. 抛出异常 when(userRepositoryMock.findById(-1L)).thenThrow(new EntityNotFoundException(用户不存在)); // 3. 根据调用参数动态返回 (使用ArgumentMatchers) when(userRepositoryMock.findByUsername(anyString())).thenAnswer( invocation - { String username invocation.getArgument(0); if (admin.equals(username)) { return Optional.of(adminUser); } else { return Optional.empty(); } } ); // 4. 模拟void方法 // 什么都不做是默认行为也可以让它抛出异常 doThrow(new RuntimeException(邮件发送失败)).when(emailServiceMock).sendWelcomeEmail(invalidemail.com); // 5. 连续打桩 (第一次调用返回A第二次返回B) when(userRepositoryMock.count()) .thenReturn(10L) // 第一次调用返回10 .thenReturn(11L); // 第二次调用返回11ArgumentMatchers如any(),eq(),anyString()在定义模拟行为时非常有用它们提供了灵活的参数匹配方式。但需要注意一旦在方法调用中使用了一个参数匹配器那么所有参数都必须使用匹配器。// 正确 when(repo.save(any(User.class))).thenReturn(mockUser); // 错误第一个参数用了匹配器any()第二个参数却用了具体值test when(repo.find(any(), test)).thenReturn(...); // 编译错误或运行时异常 // 正确使用eq()匹配器包装具体值 when(repo.find(any(), eq(test))).thenReturn(...);4.2 验证交互行为除了定义行为验证模拟对象是否按预期被调用同样重要。这就是Mockito的验证Verification功能。// 验证方法被调用了一次 verify(userRepositoryMock).findById(1L); // 验证方法被调用了特定次数 verify(userRepositoryMock, times(2)).findAll(); // 恰好2次 verify(userRepositoryMock, atLeastOnce()).save(any()); // 至少1次 verify(userRepositoryMock, atMost(5)).deleteById(anyLong()); // 最多5次 verify(userRepositoryMock, never()).findById(999L); // 从未被调用 // 验证调用顺序 InOrder inOrder inOrder(userRepositoryMock, emailServiceMock); inOrder.verify(userRepositoryMock).save(any(User.class)); inOrder.verify(emailServiceMock).sendWelcomeEmail(anyString()); // 验证方法调用时的具体参数 (使用ArgumentCaptor捕获参数进行更细致的断言) ArgumentCaptorUser userCaptor ArgumentCaptor.forClass(User.class); verify(userRepositoryMock).save(userCaptor.capture()); User capturedUser userCaptor.getValue(); assertThat(capturedUser.getUsername()).isEqualTo(newUser);4.3 SpyBean部分模拟的真实对象有时候我们不想完全模拟一个Bean而是希望它在大部分情况下保持真实行为只模拟或验证其中的一两个方法。这时可以使用SpyBean。它是真实Bean的“包装”你可以选择性地为某些方法打桩。Service public class ComplexService { public String methodA() { return Real A; } public String methodB() { return methodA() and Real B; // 内部调用了methodA } } SpringBootTest class ComplexServiceTest { SpyBean // 注入一个被“监视”的真实Bean private ComplexService complexServiceSpy; Test void testWithSpy() { // 让methodA返回一个模拟值 when(complexServiceSpy.methodA()).thenReturn(Mocked A); String result complexServiceSpy.methodB(); // 由于methodA被模拟了所以methodB内部调用的是模拟后的methodA assertThat(result).isEqualTo(Mocked A and Real B); // 验证methodA被调用过 verify(complexServiceSpy).methodA(); } }提示使用Spy时要格外小心特别是当被监视的方法是final或private时Mockito可能无法正常工作。优先考虑通过重构代码如将方法提取到另一个可模拟的组件中来避免使用Spy。5. 测试Controller层使用MockMvc进行Web层切片测试对于Spring MVC的Controller我们通常不希望启动整个Servlet容器如Tomcat来进行测试那样太慢。Spring Test提供了MockMvc它可以模拟HTTP请求和响应让我们能够对Controller进行快速、隔离的切片测试。假设我们有一个简单的UserControllerRestController RequestMapping(/api/users) public class UserController { private final UserService userService; public UserController(UserService userService) { this.userService userService; } GetMapping(/{id}) public ResponseEntityUser getUserById(PathVariable Long id) { return userService.findById(id) .map(ResponseEntity::ok) .orElse(ResponseEntity.notFound().build()); } PostMapping ResponseStatus(HttpStatus.CREATED) public User createUser(Valid RequestBody CreateUserRequest request) { return userService.registerUser(request.getUsername(), request.getEmail()); } }我们来为这个Controller编写测试。我们将使用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; WebMvcTest(UserController.class) // 只加载UserController相关的Web组件 class UserControllerTest { Autowired private MockMvc mockMvc; // 注入MockMvc用于发起模拟请求 Autowired private ObjectMapper objectMapper; // 用于JSON序列化/反序列化 MockBean private UserService userServiceMock; // Controller依赖的Service需要被模拟 Test DisplayName(GET /api/users/{id} - 用户存在返回200和用户信息) void getUserById_UserExists_ReturnsUser() throws Exception { // Given Long userId 1L; User mockUser new User(testUser, testexample.com); mockUser.setId(userId); when(userServiceMock.findById(userId)).thenReturn(Optional.of(mockUser)); // When Then mockMvc.perform(get(/api/users/{id}, userId) // 发起GET请求 .accept(MediaType.APPLICATION_JSON)) .andExpect(status().isOk()) // 期望状态码200 .andExpect(content().contentType(MediaType.APPLICATION_JSON)) // 期望内容类型是JSON .andExpect(jsonPath($.id).value(userId)) // 使用JsonPath断言JSON响应体 .andExpect(jsonPath($.username).value(testUser)) .andExpect(jsonPath($.email).value(testexample.com)); verify(userServiceMock).findById(userId); // 验证Service被调用 } Test DisplayName(GET /api/users/{id} - 用户不存在返回404) void getUserById_UserNotExists_Returns404() throws Exception { // Given Long userId 999L; when(userServiceMock.findById(userId)).thenReturn(Optional.empty()); // When Then mockMvc.perform(get(/api/users/{id}, userId)) .andExpect(status().isNotFound()); // 期望状态码404 verify(userServiceMock).findById(userId); } Test DisplayName(POST /api/users - 创建用户成功返回201和创建的用户) void createUser_ValidRequest_ReturnsCreatedUser() throws Exception { // Given CreateUserRequest request new CreateUserRequest(newUser, newexample.com); User createdUser new User(request.getUsername(), request.getEmail()); createdUser.setId(100L); when(userServiceMock.registerUser(request.getUsername(), request.getEmail())) .thenReturn(createdUser); // When Then mockMvc.perform(post(/api/users) .contentType(MediaType.APPLICATION_JSON) // 设置请求体内容类型 .content(objectMapper.writeValueAsString(request)) // 将对象序列化为JSON请求体 .accept(MediaType.APPLICATION_JSON)) .andExpect(status().isCreated()) // 期望状态码201 .andExpect(jsonPath($.id).value(100L)) .andExpect(jsonPath($.username).value(newUser)); verify(userServiceMock).registerUser(request.getUsername(), request.getEmail()); } Test DisplayName(POST /api/users - 请求体无效返回400) void createUser_InvalidRequest_Returns400() throws Exception { // Given: 创建一个无效请求用户名为空 CreateUserRequest invalidRequest new CreateUserRequest(, invalid-email); // When Then mockMvc.perform(post(/api/users) .contentType(MediaType.APPLICATION_JSON) .content(objectMapper.writeValueAsString(invalidRequest))) .andExpect(status().isBadRequest()); // 期望状态码400因为Valid注解会触发验证失败 // 由于请求无效Service方法不应被调用 verify(userServiceMock, never()).registerUser(anyString(), anyString()); } }MockMvc提供了非常流畅的DSL领域特定语言来构建请求和断言响应。andExpect方法用于添加断言jsonPath是一个强大的工具用于从JSON响应体中提取和断言值。通过WebMvcTest的切片测试我们可以将测试焦点完全集中在Web层逻辑上快速验证URL映射、参数绑定、状态码返回、异常处理等是否正确。6. 测试数据访问层使用DataJpaTest与Testcontainers测试Repository或DAO层通常需要与真实的数据库交互。Spring Boot为此提供了DataJpaTest注解。它会配置一个内存数据库如H2自动扫描Entity类并配置Spring Data JPA。默认情况下它使用事务并在每个测试结束后回滚确保测试之间互不干扰。import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest; import org.springframework.boot.test.autoconfigure.orm.jpa.TestEntityManager; DataJpaTest // 启用JPA切片测试配置内存数据库 class UserRepositoryTest { Autowired private TestEntityManager entityManager; // 用于持久化测试数据的工具 Autowired private UserRepository userRepository; // 注入真实的Repository进行测试 Test DisplayName(根据邮箱查找用户 - 成功) void findByEmail_WhenUserExists_ReturnsUser() { // Given: 使用TestEntityManager将数据持久化到测试数据库 User savedUser entityManager.persistFlushFind(new User(john, johnexample.com)); // When OptionalUser foundUser userRepository.findByEmail(johnexample.com); // Then assertThat(foundUser).isPresent(); assertThat(foundUser.get().getUsername()).isEqualTo(john); } Test DisplayName(根据不存在的邮箱查找用户 - 返回空) void findByEmail_WhenUserNotExists_ReturnsEmpty() { // When OptionalUser foundUser userRepository.findByEmail(nonexistentexample.com); // Then assertThat(foundUser).isEmpty(); } }TestEntityManager是EntityManager的替代品专门为测试设计提供了像persistFlushFind这样的便捷方法它会持久化实体、立即刷新并重新从数据库加载确保你拿到的是完全受托管的状态。然而内存数据库H2与生产数据库如PostgreSQL、MySQL在方言和特性上可能存在差异。为了进行更贴近生产环境的集成测试Testcontainers是一个绝佳的选择。它允许你在Docker容器中运行真实的数据库服务。首先在pom.xml中添加依赖dependency groupIdorg.testcontainers/groupId artifactIdjunit-jupiter/artifactId scopetest/scope /dependency dependency groupIdorg.testcontainers/groupId artifactIdpostgresql/artifactId !-- 以PostgreSQL为例 -- scopetest/scope /dependency然后编写一个使用真实PostgreSQL容器的Repository测试import org.junit.jupiter.api.Test; import org.springframework.boot.test.context.SpringBootTest; import org.testcontainers.containers.PostgreSQLContainer; import org.testcontainers.junit.jupiter.Container; import org.testcontainers.junit.jupiter.Testcontainers; Testcontainers // 启用Testcontainers支持 SpringBootTest // 需要启动完整的Spring上下文来配置DataSource AutoConfigureTestDatabase(replace AutoConfigureTestDatabase.Replace.NONE) // 禁止替换为内存数据库 class UserRepositoryIntegrationTest { Container // 定义并启动一个PostgreSQL容器 static PostgreSQLContainer? postgres new PostgreSQLContainer(postgres:15-alpine) .withDatabaseName(testdb) .withUsername(test) .withPassword(test); DynamicPropertySource // 动态地将容器连接信息注入Spring环境 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); } Autowired private UserRepository userRepository; Test void findByEmail_WithRealPostgreSQL() { // 这个测试将在真实的PostgreSQL容器中运行 User user new User(integration, integrationtest.com); userRepository.save(user); OptionalUser found userRepository.findByEmail(integrationtest.com); assertThat(found).isPresent(); } }虽然这种测试比使用H2要慢但它能发现因数据库差异导致的潜在问题对于关键的数据访问逻辑非常值得。在实际项目中可以将其作为CI/CD流水线中的一个阶段来运行。7. 高级技巧与最佳实践掌握了基础之后一些高级技巧和最佳实践能让你的测试更上一层楼。参数化测试当你需要用多组不同的输入数据来测试同一个逻辑时JUnit5的ParameterizedTest是完美工具。它避免了编写多个几乎相同的测试方法。ParameterizedTest ValueSource(strings {userexample.com, admindomain.com, testaliasmail.org}) DisplayName(验证多种格式的邮箱地址) void isValidEmail_ValidFormats_ReturnsTrue(String email) { assertThat(emailValidator.isValid(email)).isTrue(); } ParameterizedTest CsvSource({ 1, 1, 2, 2, 3, 5, 10, -5, 5 }) DisplayName(加法运算参数化测试) void add_TwoNumbers_ReturnsSum(int a, int b, int expectedSum) { Calculator calculator new Calculator(); assertThat(calculator.add(a, b)).isEqualTo(expectedSum); } // 更复杂的参数源可以从方法获取 ParameterizedTest MethodSource(provideInvalidEmails) void isValidEmail_InvalidFormats_ReturnsFalse(String email) { assertThat(emailValidator.isValid(email)).isFalse(); } private static StreamArguments provideInvalidEmails() { return Stream.of( Arguments.of(plainaddress), Arguments.of(missinglocal.com), Arguments.of(missing.com), Arguments.of() ); }测试代码结构保持测试代码的整洁和可维护性与生产代码同样重要。遵循“Given-When-Then”或“Arrange-Act-Assert”模式能让测试意图更清晰。为测试类和测试方法起描述性的名字使用DisplayName不要害怕名字长。将复杂的准备逻辑抽取到私有方法或BeforeEach中但要注意平衡过度提取可能会降低测试的可读性。测试覆盖率与质量虽然追求高测试覆盖率如80%以上是一个好目标但覆盖率数字本身不是目的。更重要的是测试的质量和有效性。要确保测试覆盖了各种边界条件、异常路径和业务规则。一个测试了所有Getter/Setter但忽略了核心业务逻辑的100%覆盖率的测试套件是毫无价值的。使用像JaCoCo这样的工具来生成覆盖率报告并将其作为发现未测试代码的指南而非终极目标。测试执行策略在大型项目中测试套件的执行时间可能很长。合理分类测试有助于优化反馈循环单元测试 快速、不依赖外部环境应在每次代码变更后立即运行。集成测试 较慢依赖数据库或其他服务可以在提交前或CI流水线中运行。端到端测试 非常慢模拟真实用户场景可以在夜间或发布前运行。可以使用JUnit5的Tag注解为测试分类然后在Maven或Gradle中配置只运行特定标签的测试。Tag(fast) Test void fastUnitTest() { /* ... */ } Tag(integration) Test SpringBootTest void integrationTest() { /* ... */ }在Maven的pom.xml中配置plugin artifactIdmaven-surefire-plugin/artifactId configuration !-- 默认运行所有不带integration标签的测试 -- groupsfast/groups /configuration /plugin plugin artifactIdmaven-failsafe-plugin/artifactId configuration !-- 在integration-test阶段运行带integration标签的测试 -- groupsintegration/groups /configuration /plugin最后记住单元测试是代码的第一道防线也是活的文档。它们应该清晰地表达代码的预期行为。当测试失败时错误信息应该能直接告诉你哪里出了问题。花时间编写好的测试会在未来的代码维护、重构和团队协作中带来数十倍的回报。在实际项目中我见过太多因为缺乏良好测试而变得脆弱、无人敢动的“祖传代码”。从今天开始为你写的每一段核心逻辑配上测试让它成为你开发流程中自然而然的一部分。