单元测试中的“替身演员”：深入浅出Mocking与Stubbing

你好！看到团队的新伙伴们在单元测试中遇到了处理外部依赖的困惑，这很正常，几乎每个开发者在成长过程中都会经历这个阶段。你们对“写代码测试代码”的理解没错，但当代码不再是孤立运行时，问题就来了。别担心，今天我们就来深入浅出地聊聊单元测试中的“替身演员”——Mocking和Stubbing，它们是如何帮助我们驯服外部依赖，让测试变得高效又可靠的。

为什么外部依赖是单元测试的“麻烦制造者”？

首先，我们得明确单元测试的核心目标：隔离被测试的单元（通常是一个函数、一个方法或一个类），验证它的逻辑是否正确，而且要快、要稳定。

但现实世界的代码往往不会独立存在，它会：

读写数据库： UserDao.getUserById(id)
调用外部API： WeatherService.getForecast(city)
操作文件系统： FileHandler.readFile(path)
发送网络请求： HttpClient.post(url, data)

这些“外部依赖”会带来什么麻烦呢？

慢：每次运行测试都要连接数据库、发起网络请求，这会大大拖慢测试速度，影响开发效率。
不稳定： 数据库数据可能变化，网络可能波动，外部服务可能宕机，导致测试结果忽红忽绿，让你对代码失去信心。
难以设置前提条件： 想象一下，为了测试一个复杂业务逻辑，你需要先往数据库里插入几十条数据，再清理掉，这不仅繁琐，还容易出错。
非确定性： 测试结果依赖于外部环境，而不是代码本身的逻辑，这严重违背了单元测试的“确定性”原则。

为了解决这些问题，我们需要一种方法，在测试时“替换”掉这些外部依赖，让被测单元在一种可控、稳定、快速的环境中运行。这时，**测试替身（Test Doubles）**就登场了！

认识测试替身（Test Doubles）：Mocking 和 Stubbing 的大家庭

“测试替身”是一个总称，它包含了几种不同的技术，用来在测试中模拟真实对象。其中最常用、也最容易混淆的就是Stub（桩对象）和Mock（模拟对象）。

我们用一个简单的例子来引入它们：假设你有一个OrderService类，它负责处理订单逻辑，需要与一个PaymentGateway（支付网关）进行交互。

// 假设这是我们的支付网关接口
interface PaymentGateway {
    boolean processPayment(String orderId, double amount);
}

// 这是我们正在测试的业务逻辑单元
class OrderService {
    private PaymentGateway paymentGateway;

    public OrderService(PaymentGateway paymentGateway) {
        this.paymentGateway = paymentGateway;
    }

    public boolean placeOrder(String orderId, double amount) {
        // 核心逻辑：检查库存、计算价格等...
        // ...

        // 关键步骤：调用支付网关处理支付
        boolean paymentSuccess = paymentGateway.processPayment(orderId, amount);

        if (paymentSuccess) {
            // 更新订单状态为已支付
            System.out.println("订单 " + orderId + " 支付成功。");
            return true;
        } else {
            // 处理支付失败逻辑
            System.out.println("订单 " + orderId + " 支付失败。");
            return false;
        }
    }
}

Stubbing (桩对象)：提供预设好的“答案”

什么是Stub？
Stub就像一个“脚本演员”：它根据预设的剧本，在被调用时返回预定的值，或者执行预定的行为。它不关心自己被调用了多少次，参数是什么，只管按剧本给出“回答”。

Stubing 的核心目的：
控制被测单元的“间接输入”——即，当被测单元调用其依赖时，该依赖返回什么数据。我们关注的是被测单元接收到什么。

何时使用Stub？
当你需要依赖对象返回特定的数据，以便让被测单元沿着某个逻辑路径执行时。例如，测试placeOrder方法在支付成功时的行为，你需要paymentGateway.processPayment方法返回true。

示例：
我们来测试placeOrder方法在支付成功时的行为。

// 假设使用Mockito框架进行测试
import static org.mockito.Mockito.*;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertTrue;

class OrderServiceTest {

    @Test
    void shouldPlaceOrderSuccessfullyWhenPaymentSucceeds() {
        // 1. 创建 PaymentGateway 的 Stub
        PaymentGateway paymentGatewayStub = mock(PaymentGateway.class);

        // 2. 为 Stub 设置预设行为 (Stubbing)
        // 当 paymentGatewayStub 的 processPayment 方法被任意字符串和任意双精度浮点数调用时，返回 true
        when(paymentGatewayStub.processPayment(anyString(), anyDouble())).thenReturn(true);

        // 3. 将 Stub 注入到 OrderService
        OrderService orderService = new OrderService(paymentGatewayStub);

        // 4. 执行被测方法
        boolean result = orderService.placeOrder("ORDER_123", 100.0);

        // 5. 验证结果
        assertTrue(result); // 验证订单是否成功放置
        // 这里我们不关心 paymentGatewayStub 被调用了多少次，或者用什么参数调用，
        // 我们只关心 OrderService 在 paymentGatewayStub 返回 true 时的行为。
    }
}

在这个例子中，paymentGatewayStub就是一个Stub。它被配置成processPayment方法无论接收到什么参数，都返回true。我们用它来模拟支付成功的场景，从而验证OrderService在支付成功后的逻辑。

Mocking (模拟对象)：验证“交互行为”

什么是Mock？
Mock更像一个“间谍”：它不仅能像Stub一样提供预设答案，更重要的是，它能记录自己被调用的情况，并且允许你在测试结束时验证这些调用是否按照预期发生了。它关心自己被调用了多少次，参数是什么。

Mocking 的核心目的：
验证被测单元的“间接输出”——即，被测单元是否按照预期与它的依赖进行了交互。我们关注的是被测单元做了什么。

何时使用Mock？
当你不仅需要控制依赖的返回值，还想验证被测单元是否正确地调用了依赖的某个方法，以及调用时的参数是否正确，或者调用了多少次。

示例：
现在我们来测试placeOrder方法在支付失败时，是否正确处理了失败逻辑，比如没有更新订单状态（这里简化为没有打印“支付成功”）。更重要的是，我们想确保PaymentGateway被调用了一次。

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

class OrderServiceTest {

    @Test
    void shouldHandlePaymentFailureWhenPaymentFails() {
        // 1. 创建 PaymentGateway 的 Mock
        PaymentGateway paymentGatewayMock = mock(PaymentGateway.class);

        // 2. 为 Mock 设置预设行为 (Stubbing)
        // 当 paymentGatewayMock 的 processPayment 方法被任意字符串和任意双精度浮点数调用时，返回 false
        when(paymentGatewayMock.processPayment(anyString(), anyDouble())).thenReturn(false);

        // 3. 将 Mock 注入到 OrderService
        OrderService orderService = new OrderService(paymentGatewayMock);

        // 4. 执行被测方法
        boolean result = orderService.placeOrder("ORDER_456", 200.0);

        // 5. 验证结果
        assertFalse(result); // 验证订单是否成功放置 (应该是失败)

        // 6. 验证 Mock 的交互行为 (Mocking)
        // 验证 paymentGatewayMock 的 processPayment 方法是否被调用了恰好一次，
        // 且调用时的参数是 "ORDER_456" 和 200.0
        verify(paymentGatewayMock, times(1)).processPayment("ORDER_456", 200.0);

        // 如果我们还想验证其他行为，比如一个日志服务是否被调用了，那也是 Mocking 的职责。
        // 例如：verify(loggerMock).logError("Payment failed for order: ORDER_456");
    }
}

在这个例子中，paymentGatewayMock既扮演了Stub的角色（返回false），又扮演了Mock的角色（记录processPayment被调用的情况，并在最后通过verify进行验证）。我们用它来模拟支付失败的场景，并验证OrderService是否正确地尝试了支付，但由于支付失败，最终返回了false。

Stubbing 与 Mocking 的核心区别与选择

特性	Stub（桩对象）	Mock（模拟对象）
核心目的	提供预设数据，控制被测单元的间接输入。	验证被测单元与依赖的交互行为，关注间接输出。
关注点	被测单元接收到什么数据，以便沿特定逻辑路径执行。	被测单元对依赖做了什么，是否正确调用了依赖的方法。
测试类型	状态验证（State-based Testing）	行为验证（Behavior-based Testing）
主要操作	`when(...).thenReturn(...)`	`verify(...)`
类比	一个提供固定答案的脚本演员	一个记录并报告行为的间谍
使用场景	模拟数据源、配置服务等，使被测单元获得所需的数据。	模拟外部系统调用、消息发送、日志记录等，验证交互。

如何选择？

当你只关心依赖返回什么数据，以使被测单元进入某种状态或执行某种逻辑时，用 Stub。
当你需要验证被测单元是否正确地调用了依赖的某个方法，调用了多少次，以及调用时的参数是否正确时，用 Mock。

一个经验法则：
不要对同一个对象既做大量的Stubbing又做大量的Mocking。通常，一个测试替身在一个测试用例中只扮演一个主要角色。如果你发现需要对同一个依赖进行复杂的返回值设置和行为验证，那可能意味着你的“单元”职责过重，或者测试用例设计得不够单一。

实用建议与最佳实践

设计可测试的代码：
- 依赖注入（Dependency Injection, DI）： 这是让你的代码容易测试的关键。通过构造函数、方法或属性注入依赖，而不是在类内部创建依赖，这样在测试时可以轻松替换为测试替身。
- 面向接口编程： 依赖具体的实现类不如依赖抽象的接口。这样，你可以为接口创建Mock或Stub，而无需修改实际代码。
保持测试的独立性、快速性和稳定性：
- 利用Mock和Stub来隔离外部依赖，确保每个单元测试都是独立的，不依赖于其他测试的执行顺序或外部环境状态。
- 避免在单元测试中直接访问数据库、文件系统或网络，使用测试替身来模拟这些交互。
只Mock你拥有和控制的接口：
- 尽量避免Mock那些不属于你的第三方库或框架。这通常意味着你的代码耦合度太高，或者你正在测试不该测试的东西。
- 不要Mock值对象（Value Objects）或简单的数据结构（如String, Integer），它们不包含复杂的行为，直接使用即可。
不要过度Mocking：
- 如果你的测试替身设置（when().thenReturn()）变得非常复杂，或者verify()语句占据了测试代码的大部分，这可能是一个警告信号。
- 过度Mocking可能会导致测试变得脆弱，当真实代码的内部实现发生微小变化时，测试就会失败，即使功能本身是正常的。这违背了测试的初衷。
- 尽量只Mock你当前测试所需的最小依赖。
明确测试意图：
- 每个单元测试都应该有一个清晰的意图：它在测试什么？在什么条件下测试？预期的结果是什么？Mock和Stub是帮助你实现这些意图的工具。

总结

单元测试是保障代码质量的基石，而Mocking和Stubbing则是处理外部依赖、实现高效可靠单元测试的强大工具。它们的核心思想都是隔离，让你的测试只关注被测单元自身的逻辑。

掌握它们不仅能让你写出更好的测试，也能促使你写出更松耦合、更易维护和扩展的代码。刚开始可能会觉得有些复杂，但多加实践，结合你们团队的实际项目，慢慢就会熟练起来。希望这篇文章能帮助新伙伴们拨开迷雾，在单元测试的道路上走得更远更稳！祝你们好运！