本文深入探讨Mockito Spy桩定方法未生效的常见问题。当生产代码独立创建实例而非使用测试中的Spy对象时，桩定将失效。核心解决方案是采用依赖注入（DI），允许测试环境注入Spy对象，生产环境注入真实对象，从而确保桩定生效，提升代码可测试性。文章将通过代码示例详细阐述这一实践。
在使用mockito进行单元测试时，spy功能允许我们部分模拟一个真实对象，即可以调用真实方法，也可以桩定（stub）特定方法的行为。然而，一个常见的误区是，即使我们对一个类的实例进行了spy并桩定了其方法，生产代码却可能仍然调用真实对象的默认行为，而不是我们预期的桩定值。
问题根源分析
问题的核心在于，Mockito的spy和mock对象是为了作为被测试单元的“依赖”而存在的。当你的生产代码在内部自行创建了GetOptionBidPrice的实例时，它使用的是一个全新的、真实的GetOptionBidPrice对象，而不是你在测试中精心构造并桩定的spyGetOptionBidPrice对象。
考虑以下生产代码片段：
// 生产代码片段 public class MyService { public double calculateValue() { // 在这里，getOptionBidPrice 是一个全新的实例 GetOptionBidPrice getOptionBidPrice = new GetOptionBidPrice(...); double bidPrice = getOptionBidPrice.getBidPrice(); // ... 使用 bidPrice 进行后续计算 return bidPrice * 2; } }
以及对应的测试代码尝试对GetOptionBidPrice进行桩定：
// 测试代码片段 @Test void testCalculateValueWithStubbedBidPrice() { GetOptionBidPrice spyGetOptionBidPrice = spy(GetOptionBidPrice.class); // 桩定 getBidPrice 方法返回 100.0 doReturn(100.0).when(spyGetOptionBidPrice).getBidPrice(); // 问题：MyService.calculateValue() 内部仍会创建新的 GetOptionBidPrice 实例 // 因此，上面桩定的 spyGetOptionBidPrice 并不会被 MyService 使用 MyService myService = new MyService(); double result = myService.calculateValue(); // 预期 result 为 200.0 (100.0 * 2)，但实际可能因为 getBidPrice 返回 0.0 而得到 0.0 assertEquals(200.0, result); }
在这种情况下，尽管你在测试中桩定了spyGetOptionBidPrice.getBidPrice()，但MyService.calculateValue()方法内部自行创建的GetOptionBidPrice实例与这个spy对象毫无关联。因此，getBidPrice()方法调用的是真实对象的默认实现，导致桩定失效。
解决方案：依赖注入 (Dependency Injection)
解决此问题的关键在于采用依赖注入（Dependency Injection，简称DI）。依赖注入是一种设计模式，它允许将对象的依赖关系从对象内部移除，转而由外部容器或框架在运行时提供。这极大地提高了代码的模块化、可测试性和可维护性。
1. 修改生产代码以接受依赖
不再在方法内部创建依赖对象，而是将其作为方法的参数或类的构造器参数传入。
修改前 (问题代码):
public class MyService { public double calculateValue() { GetOptionBidPrice getOptionBidPrice = new GetOptionBidPrice(...); // 内部创建依赖 double bidPrice = getOptionBidPrice.getBidPrice(); return bidPrice * 2; } }
修改后 (使用依赖注入):
方法参数注入：
public class MyService { // 将 GetOptionBidPrice 作为方法参数传入 public double calculateValue(GetOptionBidPrice getOptionBidPrice) { double bidPrice = getOptionBidPrice.getBidPrice(); return bidPrice * 2; } }
构造器注入 (推荐，更符合面向对象设计)：
public class MyService { private final GetOptionBidPrice getOptionBidPrice; // 通过构造器注入 GetOptionBidPrice 实例 public MyService(GetOptionBidPrice getOptionBidPrice) { this.getOptionBidPrice = getOptionBidPrice; } public double calculateValue() { double bidPrice = getOptionBidPrice.getBidPrice(); return bidPrice * 2; } }
2. 在测试中注入Spy对象
通过依赖注入，我们现在可以在测试中将桩定好的spy对象传入MyService，确保MyService内部使用的是我们期望的模拟行为。
import org.junit.jupiter.api.Test; import static org.mockito.Mockito.*; import static org.junit.jupiter.api.Assertions.assertEquals; class MyServiceTest { @Test void testCalculateValueWithStubbedBidPrice() { // 1. 创建并桩定 Spy 对象 GetOptionBidPrice spyGetOptionBidPrice = spy(new GetOptionBidPrice(...)); // 如果 GetOptionBidPrice 有构造器参数，这里需要传入 doReturn(100.0).when(spyGetOptionBidPrice).getBidPrice(); // 2. 实例化 MyService，并注入桩定好的 Spy 对象 // 如果使用构造器注入： MyService myService = new MyService(spyGetOptionBidPrice); // 如果使用方法参数注入，则在调用 calculateValue 时传入： // MyService myService = new MyService(); // 假设 MyService 还有无参构造器 // 3. 调用被测试方法 double result = myService.calculateValue(); // 如果是方法参数注入，这里传入 spyGetOptionBidPrice // 4. 验证结果 assertEquals(200.0, result, "桩定值应被正确使用并计算"); // 5. 验证 spy 方法是否被调用 (可选) verify(spyGetOptionBidPrice, times(1)).getBidPrice(); } }
3. 在生产代码中注入真实对象
在生产环境中，你将注入一个真实的GetOptionBidPrice实例。这通常通过spring、Guice等DI框架自动完成，或者手动创建并传递。
// 生产代码中的调用示例 public class ApplicationRunner { public static void main(String[] args) { // 创建真实的 GetOptionBidPrice 实例 GetOptionBidPrice realGetOptionBidPrice = new GetOptionBidPrice(...); // 创建 MyService 实例，并注入真实的依赖 MyService myService = new MyService(realGetOptionBidPrice); // 调用业务方法 double finalValue = myService.calculateValue(); System.out.println("Calculated Value: " + finalValue); } }
总结与注意事项
- 依赖注入是关键： 任何一个类或方法如果需要使用其他对象的功能，都应该通过依赖注入的方式获取这些对象，而不是在内部自行创建。这是实现高内聚、低耦合、高可测试性代码的基础。
- Spy与Mock的区别： spy用于部分模拟真实对象，保留真实行为；mock则完全模拟，所有方法默认不执行真实逻辑。无论使用哪种，它们都是为了被注入到被测试单元中。
- 构造器注入 vs. Setter注入 vs. 方法参数注入：
- 构造器注入通常是首选，因为它保证了对象在创建时就拥有所有必要的依赖，使得对象始终处于有效状态，并且依赖是不可变的。
- Setter注入允许在对象创建后设置依赖，适用于可选依赖或循环依赖（不推荐）。
- 方法参数注入适用于特定方法需要某个临时依赖的场景，但如果依赖是类级别的，则构造器注入更合适。
- 测试驱动开发 (tdd) 的实践： 遵循TDD原则，在编写功能代码之前先写测试，这会自然而然地引导你设计出易于测试的、低耦合的代码结构，其中依赖注入是不可或缺的一部分。
通过采纳依赖注入模式，你不仅解决了Mockito Spy桩定不生效的问题，更重要的是，你的代码将变得更加健壮、灵活和易于维护。
