本文旨在解决使用Mockito spy对类方法进行桩化（stubbing）时，桩化值未生效反而调用了真实方法的问题。核心原因在于生产代码直接实例化了被监控（spied）对象，而非使用测试中创建的 spy 实例。解决方案是采用依赖注入（Dependency Injection）模式，将 spy 对象作为依赖传递给生产代码，从而确保测试期间桩化行为的正确执行，提升代码的可测试性。
问题剖析：Mockito Spy桩化失效的根源
在使用mockito进行单元测试时，spy（监控）功能允许我们对真实对象进行部分模拟，即保留对象原有的行为，同时可以对特定方法进行桩化（stubbing）或验证（verification）。然而，一个常见的误区可能导致 spy 的桩化设置失效，使得测试代码预期获得桩化值，实际却调用了真实方法并返回其默认值或实际计算结果。
问题的核心在于，如果你的生产代码（即被测试的代码）在内部自行创建了 spy 对象所代表的类实例，那么你在测试代码中创建并桩化的 spy 实例将不会被生产代码使用。生产代码将操作一个全新的、未经桩化的实例。
考虑以下代码示例：
依赖类 (GetOptionBidPrice.Java)
// 假设这是一个负责获取期权投标价格的类 public class GetOptionBidPrice { public double getBidPrice() { // 实际的业务逻辑，可能涉及网络请求或复杂计算 System.out.println("调用了 GetOptionBidPrice 的真实 getBidPrice() 方法"); return 0.0; // 假设真实方法默认返回0.0 } }
被测试的业务逻辑类 (MyService.java) – 错误示范
public class MyService { // 这种方法内部直接创建 GetOptionBidPrice 实例 public double calculateTotalBidPriceProblematic() { GetOptionBidPrice getOptionBidPrice = new GetOptionBidPrice(); // 问题所在：内部自行创建实例 double bidPrice = getOptionBidPrice.getBidPrice(); return bidPrice * 2; } }
测试代码 (MyServiceTest.java) – 桩化失效的场景
import org.junit.jupiter.api.Test; import static org.mockito.Mockito.*; import static org.junit.jupiter.api.Assertions.*; public class MyServiceTest { @Test void testCalculateTotalBidPriceProblematic_StubbingFails() { // 尝试对 GetOptionBidPrice 进行 spy 并桩化 GetOptionBidPrice spyGetOptionBidPrice = spy(new GetOptionBidPrice()); doReturn(100.0).when(spyGetOptionBidPrice).getBidPrice(); // 桩化 getBidPrice 方法返回 100.0 MyService myService = new MyService(); // 调用被测试方法 double result = myService.calculateTotalBidPriceProblematic(); // 预期结果应为 100.0 * 2 = 200.0，但实际会是 0.0 * 2 = 0.0 // 因为 myService 内部创建了一个新的 GetOptionBidPrice 实例，而不是使用了 spyGetOptionBidPrice System.out.println("实际结果: " + result); assertEquals(0.0, result, "桩化未生效，真实方法被调用"); // 断言会失败，因为结果是0.0 verify(spyGetOptionBidPrice, never()).getBidPrice(); // 验证 spy 上的方法从未被调用 } }
在上述示例中，尽管我们在测试中对 spyGetOptionBidPrice 进行了桩化，但 MyService 内部的 calculateTotalBidPriceProblematic 方法却创建了它自己的 GetOptionBidPrice 实例。因此，MyService 操作的是一个全新的、未经桩化的对象，导致我们的桩化设置完全失效。
解决方案：拥抱依赖注入
解决这一问题的核心思想是依赖注入（Dependency Injection, DI）。依赖注入是一种设计模式，它允许一个对象接收其所依赖的其他对象，而不是在内部自行创建这些依赖。这极大地提高了代码的模块化、可测试性和可维护性。
通过依赖注入，我们可以在测试时将我们准备好的 spy 实例“注入”到被测试的对象中，从而确保被测试对象使用的是我们期望的、已被桩化的实例。
被测试的业务逻辑类 (MyService.java) – 正确示范
public class MyService { // 通过构造函数或方法参数注入 GetOptionBidPrice 实例 // 推荐使用构造函数注入，使依赖关系更明确 private final GetOptionBidPrice getOptionBidPrice; // 构造函数注入 public MyService(GetOptionBidPrice getOptionBidPrice) { this.getOptionBidPrice = getOptionBidPrice; } // 或者使用方法参数注入（适用于单次操作的依赖） public double calculateTotalBidPriceCorrect(GetOptionBidPrice getOptionBidPrice) { double bidPrice = getOptionBidPrice.getBidPrice(); return bidPrice * 2; } // 如果是构造函数注入，方法体如下 public double calculateTotalBidPriceUsingInjectedInstance() { double bidPrice = this.getOptionBidPrice.getBidPrice(); return bidPrice * 2; } }
测试代码 (MyServiceTest.java) – 桩化成功的场景
import org.junit.jupiter.api.Test; import static org.mockito.Mockito.*; import static org.junit.jupiter.api.Assertions.*; public class MyServiceTest { @Test void testCalculateTotalBidPriceCorrect_StubbingSuccess() { // 1. 创建 GetOptionBidPrice 的真实实例（如果 spy 需要基于真实对象） GetOptionBidPrice realGetOptionBidPrice = new GetOptionBidPrice(); // 2. 创建 spy 实例 GetOptionBidPrice spyGetOptionBidPrice = spy(realGetOptionBidPrice); // 3. 对 spy 实例的特定方法进行桩化 doReturn(100.0).when(spyGetOptionBidPrice).getBidPrice(); // 桩化 getBidPrice 方法返回 100.0 // 4. 实例化 MyService，并通过依赖注入传入 spy 实例 MyService myService = new MyService(spyGetOptionBidPrice); // 使用构造函数注入 // 5. 调用被测试方法 double result = myService.calculateTotalBidPriceUsingInjectedInstance(); // 6. 验证和断言 verify(spyGetOptionBidPrice, times(1)).getBidPrice(); // 验证 spy 上的 getBidPrice 方法被调用了一次 assertEquals(200.0, result, "桩化成功，结果符合预期"); // 断言成功，结果为 200.0 System.out.println("实际结果: " + result); } @Test void testCalculateTotalBidPriceCorrect_MethodInjectionSuccess() { // 1. 创建 GetOptionBidPrice 的真实实例 GetOptionBidPrice realGetOptionBidPrice = new GetOptionBidPrice(); // 2. 创建 spy 实例 GetOptionBidPrice spyGetOptionBidPrice = spy(realGetOptionBidPrice); // 3. 对 spy 实例的特定方法进行桩化 doReturn(100.0).when(spyGetOptionBidPrice).getBidPrice(); // 4. 实例化 MyService (此时可以无参构造，如果 MyService 还有其他依赖) MyService myService = new MyService(new GetOptionBidPrice()); // 假设 MyService 构造函数需要一个 GetOptionBidPrice，这里传入一个普通实例 // 或者 MyService 也可以有无参构造，如果它不依赖 GetOptionBidPrice 除非通过方法注入 // 5. 调用被测试方法，并通过方法参数注入 spy 实例 double result = myService.calculateTotalBidPriceCorrect(spyGetOptionBidPrice); // 6. 验证和断言 verify(spyGetOptionBidPrice, times(1)).getBidPrice(); assertEquals(200.0, result, "桩化成功，结果符合预期"); System.out.println("实际结果: " + result); } }
通过依赖注入，我们成功地将测试中准备好的 spy 实例传递给了 MyService，确保了 MyService 在执行业务逻辑时，调用的是我们已经桩化的 GetOptionBidPrice 实例，从而使测试能够准确地验证预期行为。
注意事项与最佳实践
- 何时使用 spy vs mock：
- 依赖注入的重要性：
- 提高可测试性： 这是依赖注入最直接的优势。通过注入依赖，你可以轻松地在测试中替换真实依赖为模拟或桩化对象。
- 降低耦合度： 对象不再负责创建其依赖，而是接收它们，这使得组件之间更加独立。
- 提高可维护性： 依赖关系清晰，更易于理解和修改。
- 促进测试驱动开发（tdd）： 在编写代码之前考虑如何测试，自然会倾向于设计易于注入依赖的组件。
- 避免在生产代码中直接实例化依赖： 除非依赖是一个简单的、无状态的工具类，并且其行为在任何情况下都是确定且无副作用的，否则应尽量避免在方法或类内部直接 new 依赖对象。这会使得单元测试变得困难，因为你无法替换这些内部创建的依赖。
- 构造函数注入是首选： 对于一个类必需的依赖，通常推荐使用构造函数注入。这使得类的依赖关系在对象创建时就明确可见，并且保证了对象在创建后处于有效状态。
通过理解 spy 的工作原理并结合依赖注入的最佳实践，我们可以构建出更健壮、更易于测试和维护的java应用程序。
