Java 软件测试（二）：Mockito与JUnit 5应用
单元测试在现代Java开发中早已不是锦上添花，而是实打实的刚需。尤其是在微服务架构当道的今天，一个改动可能牵动十来个服务，没有一套可靠的单元测试兜底，线上出问题的概率会直线上升。
Mockito作为Java生态圈里使用最广的模拟框架，搭配JUnit 5强大的测试引擎，几乎成了Java单元测试的标配。这两者合在一起，不仅能写出干净利落的测试代码，还能把数据库、网络调用这些外部依赖牢牢隔离，让测试结果更可靠、更稳定。
1. Mockito核心机制解析
Mockito的设计思路很直白：用虚拟对象替代真实依赖，让测试只关注目标逻辑本身。这在处理数据库连接、远程调用或者复杂业务流程时，效果尤其明显。
1.1 Mock对象的本质
Mock对象本质上就是个“替身”，它可以模拟真实对象的行为，但决不会真的去执行那些实际逻辑。举个例子，测试用户服务时，我们并不想让代码真的去查数据库——万一数据变了、连接超时了，测试就全崩了。这时候Mock对象就能完美扮演那个“假装查数据库”的角色。
它能提前设置好方法的返回值，记录方法被调用了多少次，甚至可以故意抛出异常来测试异常处理逻辑。这样一来，我们就可以把注意力完全放在业务代码的正确性上，不用担心外部依赖的干扰。
1.2 常用API详解
@Mock注解是最基础的操作：告诉Mockito给某个字段创建一个模拟对象。只需在字段上加上这个注解，框架就自动帮你搞定。
when()方法用来定义模拟对象的行为。比如when(userDao.findById(1)).thenReturn(user)，意思就是“当调用findById(1)时，给我返回指定的user对象”。
verify()方法则用来验证模拟对象是否按预期被调用。这在测试方法调用逻辑时特别有用——可以确认某些关键方法确实被执行了，或者确保某个方法恰好被调用了指定次数。
1.3 高级功能应用
@Captor注解可以捕获方法调用时的参数。当你需要验证传给某个方法的参数是否正确时，比如检查传入的复杂对象是否包含预期的字段，用Captor就能轻松拿到参数内容。
ArgumentMatchers提供了丰富的参数匹配功能，比如any()匹配任意参数、eq()匹配精确值、contains()匹配字符串包含关系等。这些灵活的工具让参数验证变得非常方便。
2. JUnit 5新特性探索
JUnit 5相比之前的版本有了脱胎换骨的变化。不光是架构更模块化，功能上也强大了一大截。
2.1 架构重构
JUnit 5采用了全新的三模块架构：JUnit Platform、JUnit Jupiter和JUnit Vintage。Platform负责提供测试引擎的基础设施，Jupiter是新的编程模型和扩展机制，Vintage则保证向后兼容，让老的JUnit 4测试也能跑起来。
这种设计让JUnit 5具备了极佳的扩展性——你可以自由选择不同的测试引擎，甚至可以在同一个项目中混用不同版本的测试风格。
2.2 注解系统升级
新的注解系统更加直观易用。@BeforeEach和@AfterEach替代了旧的@Before和@After，名字本身就把执行时机说清楚了。
@DisplayName注解允许你给测试方法起一个更友好的描述性名称，生成测试报告时显示出来比方法名直观得多。
@ParameterizedTest支持参数化测试——一个测试方法可以接受多组不同的输入数据，一次性运行所有组合，大大减少了重复代码的编写量。
2.3 条件测试与嵌套结构
条件测试功能让你可以根据运行环境动态决定是否执行某些测试。比如@EnabledOnOs可以指定只在Linux或者Windows上运行某个测试，避免平台相关的测试在其他环境下误报。
@Nested注解支持嵌套测试类。当测试比较多时，可以把相关的测试组织到内部类里，让整个测试结构更有层次感，也更容易维护。
3. 环境搭建与基础实践
3.1 依赖配置
要在项目里用上Mockito和JUnit 5，首先得把依赖加进去。Maven项目可以在pom.xml里添加以下配置：
3.2 基础测试示例
下面是一个简单的测试类，展示了Mockito和JUnit 5的基本配合方式：
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.Mock;
import org.mockito.InjectMocks;
import org.mockito.junit.jupiter.MockitoExtension;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.*;
@ExtendWith(MockitoExtension.class)
class UserServiceTest {
@Mock
private UserRepository userRepository;
@InjectMocks
private UserService userService;
@Test
void shouldReturnUserWhenValidId() {
// 准备测试数据
User expectedUser = new User(1L, "张三", "zhangsan@example.com");
when(userRepository.findById(1L)).thenReturn(expectedUser);
// 执行测试
User actualUser = userService.getUserById(1L);
// 验证结果
assertEquals(expectedUser.getName(), actualUser.getName());
verify(userRepository).findById(1L);
}
}
这个例子展示了最基本的测试三步骤：准备数据（Given）、执行方法（When）、验证结果（Then）。
4. 实际业务场景应用
4.1 电商订单处理测试
在电商系统里，一个订单的处理往往要同时调动好几个服务：检查库存、处理支付、发送通知等等。这种多服务协作的场景，正是Mockito大显身手的地方。
@ExtendWith(MockitoExtension.class)
class OrderServiceTest {
@Mock
private InventoryService inventoryService;
@Mock
private PaymentService paymentService;
@Mock
private NotificationService notificationService;
@InjectMocks
private OrderService orderService;
@Test
void shouldProcessOrderSuccessfully() {
// 模拟库存充足
when(inventoryService.checkStock("ITEM001", 2)).thenReturn(true);
// 模拟支付成功
when(paymentService.processPayment(any(PaymentRequest.class)))
.thenReturn(new PaymentResult(true, "PAY123"));
OrderRequest request = new OrderRequest("ITEM001", 2, 100.0);
OrderResult result = orderService.processOrder(request);
assertTrue(result.isSuccess());
verify(inventoryService).reserveStock("ITEM001", 2);
verify(notificationService).sendOrderConfirmation(any());
}
@Test
void shouldFailWhenInsufficientStock() {
when(inventoryService.checkStock("ITEM001", 5)).thenReturn(false);
OrderRequest request = new OrderRequest("ITEM001", 5, 250.0);
OrderResult result = orderService.processOrder(request);
assertFalse(result.isSuccess());
assertEquals("库存不足", result.getErrorMessage());
// 确保没有调用支付服务
verifyNoInteractions(paymentService);
}
}
4.2 异常处理测试
实际开发中，异常处理是绕不开的硬骨头。我们需要确保系统在遇到异常时能妥善应对，而不是直接挂了。下面这个例子就演示了支付超时情况下的处理逻辑：
@Test
void shouldHandlePaymentException() {
when(inventoryService.checkStock(anyString(), anyInt())).thenReturn(true);
when(paymentService.processPayment(any()))
.thenThrow(new PaymentException("支付网关超时"));
OrderRequest request = new OrderRequest("ITEM001", 1, 50.0);
assertThrows(OrderProcessingException.class, () -> {
orderService.processOrder(request);
});
// 验证库存被释放
verify(inventoryService).releaseStock("ITEM001", 1);
}
4.3 参数捕获与验证
有时候我们需要检查传递给某个依赖服务的参数是否准确——比如通知服务收到的订单号对不对。这时候ArgumentCaptor就派上用场了：
@Test
void shouldSendCorrectNotification() {
ArgumentCaptor
5. 测试驱动开发实践
5.1 TDD基本流程
测试驱动开发遵循经典的“红-绿-重构”循环。先写一个会失败的测试（红），然后写最少量的代码让测试通过（绿），最后在绿的前提下重构代码（重构）。
假设我们要写一个计算器类。首先写测试：
@Test
void shouldAddTwoNumbers() {
Calculator calculator = new Calculator();
int result = calculator.add(3, 5);
assertEquals(8, result);
}
这时候测试必定失败——Calculator类还不存在。然后我们写出最简实现：
public class Calculator {
public int add(int a, int b) {
return a + b;
}
}
测试通过后，再看有没有需要改进的地方。比如添加参数验证、支持更多数据类型等。
5.2 复杂业务的TDD
对于较复杂的业务逻辑，TDD同样适用。比如用户注册功能：
@Test
void shouldRegisterUserSuccessfully() {
// 模拟邮箱不存在的情况，返回false表示邮箱可用
when(userRepository.existsByEmail("test@example.com")).thenReturn(false);
// 模拟密码加密过程，返回加密后的密码
when(passwordEncoder.encode("password123")).thenReturn("encoded_password");
// 模拟用户保存操作，any(User.class)表示接受任何User类型的参数
when(userRepository.sa ve(any(User.class))).thenReturn(sa vedUser);
// 创建注册请求对象，包含邮箱和密码
RegisterRequest request = new RegisterRequest("test@example.com", "password123");
// 调用用户服务的注册方法
RegisterResult result = userService.register(request);
// 断言注册结果为成功
assertTrue(result.isSuccess());
// 验证邮件服务的欢迎邮件发送方法被调用了一次
verify(emailService).sendWelcomeEmail("test@example.com");
}
@Test
void shouldFailWhenEmailAlreadyExists() {
// 模拟邮箱已存在的情况，返回true表示邮箱已被占用
when(userRepository.existsByEmail("existing@example.com")).thenReturn(true);
// 创建注册请求，使用已存在的邮箱
RegisterRequest request = new RegisterRequest("existing@example.com", "password123");
// 执行注册操作
RegisterResult result = userService.register(request);
// 断言注册失败
assertFalse(result.isSuccess());
// 验证错误消息内容是否正确
assertEquals("邮箱已被注册", result.getErrorMessage());
}
6. 持续集成中的测试策略
6.1 CI环境配置
在持续集成环境里，单元测试是代码质量的第一道防线。每次代码提交都应该触发完整的测试套件。
Maven项目可以通过以下命令运行测试：
mvn clean test
Gradle项目则使用：
./gradlew clean test
6.2 测试报告生成
现代CI工具都支持JUnit测试报告的解析和展示。在Maven里可以配置surefire插件来生成详细报告：
6.3 测试覆盖率监控
用JaCoCo之类的工具可以监控测试覆盖率，实时掌握代码的健康状况：
7. 总结
测试命名规范：好的测试名称应当清晰表达意图。推荐使用“should...When...”的格式，比如shouldReturnUserWhenValidIdProvided，一目了然。
测试数据管理：测试数据应该独立且可预测。避免使用随机数据，尽量用固定的测试数据集。可以考虑用测试数据构建器模式来简化数据创建。
Mock使用原则：不要过度使用Mock。只对那些难以构造、执行缓慢或者有副作用的依赖使用Mock。对于简单的值对象，直接创建真实对象往往更简单。
测试代码同样需要维护。当业务逻辑发生变化时，相应的测试也得跟着更新。保持测试代码的简洁和可读性，避免“为了测试而测试”造成的过度复杂化。
