在使用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桩定不生效的问题，更重要的是，你的代码将变得更加健壮、灵活和易于维护。
