クラスの方法におけるモッキートスパイのパイル故障の問題を解決する方法：依存噴射のための実用的なガイド

本文旨在解决使用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 实例，从而使测试能够准确地验证预期行为。

注意事项与最佳实践

1. 何时使用 spy vs mock：
   • mock： 当你需要完全模拟一个对象，不关心其真实行为，或者真实行为难以测试（如外部服务调用、数据库操作）时，使用 mock。mock 对象默认所有方法都不执行真实逻辑，并返回默认值（如 null、0、false）。
   • spy： 当你需要部分模拟一个真实对象时使用 spy。spy 对象会执行真实方法，除非你明确地桩化了特定方法。它适用于测试那些复杂对象中只有少数方法需要被控制的场景。
2. 依赖注入的重要性：
   • 提高可测试性： 这是依赖注入最直接的优势。通过注入依赖，你可以轻松地在测试中替换真实依赖为模拟或桩化对象。
   • 降低耦合度： 对象不再负责创建其依赖，而是接收它们，这使得组件之间更加独立。
   • 提高可维护性： 依赖关系清晰，更易于理解和修改。
   • 促进测试驱动开发（TDD）： 在编写代码之前考虑如何测试，自然会倾向于设计易于注入依赖的组件。
3. 避免在生产代码中直接实例化依赖： 除非依赖是一个简单的、无状态的工具类，并且其行为在任何情况下都是确定且无副作用的，否则应尽量避免在方法或类内部直接 new 依赖对象。这会使得单元测试变得困难，因为你无法替换这些内部创建的依赖。
4. 构造函数注入是首选： 对于一个类必需的依赖，通常推荐使用构造函数注入。这使得类的依赖关系在对象创建时就明确可见，并且保证了对象在创建后处于有效状态。

通过理解 spy 的工作原理并结合依赖注入的最佳实践，我们可以构建出更健壮、更易于测试和维护的Java应用程序。

以上がクラスの方法におけるモッキートスパイのパイル故障の問題を解決する方法：依存噴射のための実用的なガイドの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。