单元测试模拟依赖方法的几种方式

本文深入探讨了如何利用 Mockito 的 spy 与 thenAnswer（实际应为 doAnswer）实现精准的部分模拟（partial mocking），帮助开发者在单元测试中安全、灵活地拦截并重定义同一对象内被调用方法的行为——尤其适用于 method1 内部调用同实例 method2 且需根据真实运行时参数动态返回定制结果的复杂场景；通过真实可运行示例和关键细节剖析（如为何必须用 doAnswer 而非 when+thenAnswer、如何安全提取参数、匹配器选择及设计警示），不仅解决了“间接调用难模拟”的痛点，更引导读者反思代码可测性本质：在必要时巧妙使用部分模拟的同时，也推动面向接口、职责分离的高质量重构。

本文介绍使用 Mockito 的 spy 与 thenAnswer 实现部分模拟（partial mock），精准控制被测方法内部调用的其他方法的行为，尤其适用于需自定义传入参数并返回预期结果的场景。

本文介绍使用 Mockito 的 spy 与 thenAnswer 实现部分模拟（partial mock），精准控制被测方法内部调用的其他方法的行为，尤其适用于需自定义传入参数并返回预期结果的场景。

在实际开发中，我们常遇到一个方法（如 method1）内部调用同一类中的另一个方法（如 method2），而该被调用方法又依赖外部逻辑或难以测试的计算。此时，若想为 method1 编写可预测、可隔离的单元测试，不应直接测试 method2 的真实行为，而应对其“按需拦截”——即当 method1 调用 method2 时，由测试框架接管调用，并允许我们动态读取原始参数、注入自定义逻辑、返回指定结果。

这正是 部分模拟（Partial Mocking） 的典型用例。核心思路是：使用 Mockito.spy() 包装真实对象（而非完全替换），再通过 when(...).thenAnswer(...) 拦截对目标方法（如 method2）的调用，利用 InvocationOnMock 获取运行时传入的实际参数，并据此构造返回值。

以下是一个完整可运行的示例（基于你的代码结构重构）：

public class Calculator {
    public int method1(int a, int b, int c) {
        // 对 c 做一些处理（例如校验、转换等）
        int processedC = c * 2;
        return method2(a, b, 1, 3); // 注意：此处硬编码了 g=1, h=3
    }

    public int method2(int a, int b, int g, int h) {
        return a + b + g + h;
    }
}

对应测试代码如下：

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.*;

import org.junit.jupiter.api.Test;
import org.mockito.invocation.InvocationOnMock;

class CalculatorTest {

    @Test
    void testMethod1_withCustomizedMethod2Behavior() {
        // 创建被测对象的部分模拟（spy）
        Calculator calculator = spy(new Calculator());

        // 拦截 method2 调用：无论原始参数是什么，我们都返回 a * b + 100
        doAnswer(invocation -> {
            int a = invocation.getArgument(0, Integer.class);
            int b = invocation.getArgument(1, Integer.class);
            // 忽略 g 和 h，注入自定义逻辑
            return a * b + 100;
        }).when(calculator).method2(anyInt(), anyInt(), anyInt(), anyInt());

        // 执行被测方法（它内部会调用被拦截的 method2）
        int result = calculator.method1(10, 20, 5);

        // 验证结果符合我们的模拟逻辑：10 * 20 + 100 = 300
        assertEquals(300, result);
    }
}

✅ 关键要点说明：

• 使用 spy() 而非 mock()：确保 method1 的真实逻辑执行，仅对 method2 进行干预；
• 使用 doAnswer(...).when(...) 而非 when(...).thenAnswer(...)：因为 method2 是被 method1 内部调用的（即“间接调用”），when().thenAnswer() 在 spy 场景下可能因未触发而导致空指针或不生效；doAnswer 更安全可靠；
• invocation.getArgument(index, Type.class) 提供类型安全的参数提取，避免强制类型转换；
• anyInt() 等匹配器确保无论 method1 如何传参，该模拟均生效；如需更精确控制（例如只拦截特定参数组合），可改用具体值匹配（如 eq(10), eq(20), ...）。

⚠️ 注意事项：

• spy() 无法拦截 private、static、final 方法或构造器调用，如需此类能力，需借助 PowerMock（已不推荐）或迁移到更现代方案（如使用接口抽象 + 依赖注入，或采用 @ExtendWith(MockitoExtension.class) + @InjectMocks 组合设计）；
• 过度依赖 partial mocking 可能暗示类职责过重或耦合过高，建议结合重构（如将 method2 抽取为独立服务并注入）提升可测性与设计质量；
• 测试中应明确注释模拟意图（如“模拟 method2 返回 a*b+100 以隔离外部计算”），增强可维护性。

通过这种方式，你不仅能精准控制 method1 中 method2 的行为，还能让测试真正聚焦于 method1 的业务逻辑验证——这才是高质量单元测试的核心价值。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。