1. 为什么我们需要Mock测试在开发Spring Boot微服务时单元测试经常会遇到一个棘手问题被测代码依赖数据库、第三方服务或其他外部组件。想象一下你正在测试一个用户查询服务但它需要连接真实的数据库。这时你会面临几个挑战测试环境数据库可能不稳定测试数据难以准备和维护测试执行速度变慢无法模拟异常场景我去年参与的一个电商项目就遇到过这种情况。当时我们有一个订单服务依赖支付网关和库存服务。每次跑单元测试都要启动所有依赖服务整个测试套件跑完要15分钟开发效率极低。Mock测试通过创建虚拟对象来模拟这些依赖项的行为。就像拍电影时用替身演员完成危险动作一样Mock对象可以模拟正常返回值抛出指定异常验证调用参数和次数完全隔离被测代码2. Mockito基础实战2.1 快速创建Mock对象Mockito提供了两种创建Mock对象的方式// 方式1使用静态方法 UserRepository mockRepo Mockito.mock(UserRepository.class); // 方式2使用注解需要搭配MockitoJUnitRunner RunWith(MockitoJUnitRunner.class) public class UserServiceTest { Mock private UserRepository userRepository; }我更喜欢第二种方式代码更简洁。但要注意如果使用Mock注解必须调用MockitoAnnotations.initMocks(this)或在测试类上添加RunWith(MockitoJUnitRunner.class)。2.2 基本打桩(stubbing)方法打桩就是预设Mock对象的行为。Mockito最常用的打桩方法是when().thenReturn()// 模拟正常返回值 when(userRepository.findById(1L)).thenReturn(Optional.of(new User(1L, 张三))); // 模拟抛出异常 when(userRepository.findById(2L)).thenThrow(new RuntimeException(用户不存在)); // 模拟连续调用不同返回值 when(userRepository.count()) .thenReturn(10L) .thenReturn(20L);实际项目中我经常用这些技巧来测试边界条件。比如模拟数据库连接超时、服务不可用等异常场景。2.3 验证交互行为验证是Mock测试的重要环节确保被测代码按预期调用了依赖对象// 验证方法被调用一次 verify(userRepository).findById(1L); // 验证方法从未被调用 verify(userRepository, never()).deleteById(any()); // 验证方法被调用至少两次 verify(userRepository, atLeast(2)).save(any(User.class)); // 验证调用顺序 InOrder inOrder inOrder(userRepository); inOrder.verify(userRepository).findById(1L); inOrder.verify(userRepository).save(any(User.class));在金融项目中我们曾用顺序验证发现了一个严重的业务流程缺陷系统在验证账户余额前就执行了转账操作。3. 处理复杂场景3.1 参数匹配器当你不关心具体参数值时可以使用Mockito的参数匹配器// 匹配任何Long类型参数 when(userRepository.findById(anyLong())).thenReturn(...); // 自定义匹配器 when(userRepository.findByAge(argThat(age - age 18))).thenReturn(...); // 混合使用精确匹配和模糊匹配 when(userRepository.update( eq(1L), // 必须等于1 anyString() // 任意字符串 )).thenReturn(1);踩坑提醒如果方法有多个参数不能部分使用匹配器。要么全部用精确值要么全部用匹配器。3.2 Spy部分Mock有时你只想Mock对象的某些方法其他方法保持真实行为。这时可以用SpyListString realList new ArrayList(); ListString spyList spy(realList); // 调用真实方法 spyList.add(real); // 打桩size()方法 doReturn(100).when(spyList).size(); System.out.println(spyList.size()); // 100 System.out.println(spyList.get(0)); // real重要提示Spy对象使用doReturn().when()语法而不是when().thenReturn()否则真实方法会被调用。4. PowerMock解决难题4.1 为什么需要PowerMockMockito虽然强大但无法Mock以下场景静态方法私有方法final类/方法构造函数这时就需要PowerMock出场了。它通过字节码操作扩展了Mockito的功能。4.2 Mock静态方法假设我们有一个工具类public class AuthUtils { public static boolean isAdmin() { // 复杂逻辑... } }测试代码RunWith(PowerMockRunner.class) PrepareForTest(AuthUtils.class) public class OrderServiceTest { Test public void testAdminOrder() { // 1. 准备静态类 PowerMockito.mockStatic(AuthUtils.class); // 2. 打桩静态方法 when(AuthUtils.isAdmin()).thenReturn(true); // 3. 执行测试 OrderService service new OrderService(); Order result service.createOrder(...); // 4. 验证 verifyStatic(AuthUtils.class); AuthUtils.isAdmin(); } }4.3 Mock私有方法对于包含复杂私有方法的类public class PaymentService { private boolean validateCard(String cardNo) { // 复杂验证逻辑 } }测试代码RunWith(PowerMockRunner.class) PrepareForTest(PaymentService.class) public class PaymentServiceTest { Test public void testInvalidCard() throws Exception { PaymentService spy PowerMockito.spy(new PaymentService()); // 打桩私有方法 when(spy, validateCard, anyString()).thenReturn(false); PaymentResult result spy.processPayment(invalid_card); assertEquals(INVALID_CARD, result.getCode()); } }5. 最佳实践与常见陷阱5.1 测试金字塔原则根据测试金字塔单元测试应该是数量最多的测试类型。我建议的Mock测试原则只Mock直接依赖每个测试用例只测一个功能点保持测试代码和生产代码同等质量测试名称应体现业务场景5.2 常见问题排查问题1Mock对象行为不符合预期检查是否调用了initMocks()确认没有在Mock对象上调用真实方法检查打桩顺序后面的打桩会覆盖前面的问题2PowerMock不生效确保使用RunWith(PowerMockRunner.class)检查PrepareForTest是否包含目标类确认依赖版本兼容PowerMock和Mockito版本匹配问题3测试随机失败避免在Mock对象上使用随机值确保测试之间完全隔离检查静态变量是否被污染6. 真实项目案例去年我们重构了一个老旧的订单系统代码中到处都是静态工具类和私有方法。使用PowerMockMockito组合我们成功为这个遗留系统添加了单元测试覆盖。具体步骤先用PowerMock处理静态方法和私有方法逐步重构代码将静态方法改为实例方法用Mockito替换PowerMock的用法最终移除了PowerMock依赖这个案例让我明白Mock工具是手段而非目的最终目标是写出可测试的代码。