什么是 Mocking？深入浅出解析测试替身与单元测试实践

2026-02-07 06:24:26 0条评论 1次阅读 0人点赞

在软件开发中，你是否曾经遇到过这样的困境：当你试图为一个依赖于复杂外部系统（如数据库、第三方支付网关或天气API）的函数编写单元测试时，由于这些外部环境的不确定性，测试变得难以控制，甚至因为网络波动而随机失败？这正是我们引入“Mocking（模拟）”技术的原因。

Mocking 是软件测试中一种非常强大的技术，它涉及创建真实对象的“模拟版本”，即“测试替身”，以便在受控环境中模拟它们的行为。这使得开发者能够独立测试某些组件或功能，而无需受制于整个系统或其他外部依赖。通过使用 Mocks，我们可以控制测试条件，从而在不受现实世界中不可预测因素干扰的情况下，测试组件如何应对极端情况和故障。Mocking 还为开发者提供了一种方法来追踪组件之间的交互，确保它们按预期进行通信并正确处理数据。

在本文中，我们将深入探讨 Mocking 的核心概念，剖析不同类型的测试替身，并通过实际的代码示例展示如何在实际项目中高效地应用这些技术，从而让你的单元测试更加健壮、快速且可维护。

理解测试替身：Mocks、Stubs、Fakes 和 Spies

在软件测试中，隔离和测试组件的关键方法之一是使用测试替身。测试替身是真实对象的替身，具有相似的行为外观，我们可以对其进行控制以测试某些功能，而无需调用实际的实现。基本上，根据用例的不同，这些替身可以分为多种类型。理解它们之间的细微差别，是编写专业测试代码的第一步。

Mocks（模拟对象）：行为验证者

Mock 是最常被提及（也常被误用）的测试替身。它们是根据其使用预期预先编程的对象。Mock 不仅仅是提供一个假的返回值，更重要的是，它们会检查测试运行期间是否发生了特定的交互——例如，使用特定参数的方法调用——如果不符合设定的预期，则会使测试失败。

Mock 对于测试与外部服务或系统其他部分交互的组件行为特别有用。我们关注的是“你是如何与它交互的”，而不仅仅是“你得到了什么结果”。

Stubs（桩件）：状态提供者

Stubs 是为特定调用提供固定响应的实现。与 Mocks 不同，Stubs 不关心交互过程；它们只是确保使用准备好的数据继续进行测试。当你想要隔离一个为被测单元提供数据的组件时，Stubbing 非常有用，例如一个返回预定义结果的数据库查询。

简而言之，Stubs 负责回答“当输入 X 时，返回 Y”，而不会验证你是否真的调用了它。

Fakes（伪造品）：轻量级实现

Fakes 是更复杂的一类测试替身，它们具有可用的实现，但代表了所涉及组件的简化版本。例如，内存数据库可以在测试期间伪造真实的数据库。这可以使测试运行得更快，并避免外部依赖。通常，当某个组件的行为过于复杂而难以轻松 Mock 或 Stub，但测试又不需要完整实现时，我们会使用 Fakes。

一个经典的例子是使用 INLINECODE45e9e77d 来作为数据库的 Fake，或者使用一个直接返回数据的 INLINECODEfec82755 来替代真实的 HTTP 请求。

Spies（间谍）：部分模拟与监听

虽然 Spies 与 Mocks 非常相似，但它们真正侧重于记录与对象的交互，即调用了哪些方法以及使用了哪些参数。测试结束后，我们可以检查 Spy 以确保交互按预期发生。与 Mocks 不同，Spies 通常包装在真实对象上，如果某些方法没有被显式模拟，它们会默认调用真实对象的逻辑。如果交互不符合预期，Spies 不会导致测试失败；它们只是让测试继续进行并为断言提供数据。

Mocking 在单元测试中的作用

Mocking 在单元测试中扮演着关键角色，通过模拟外部依赖或系统其他部分的实现细节，可以有效地隔离并测试系统的单个组件。单元测试的主要重点是确保特定的代码——无论是函数、方法还是类——在所有条件下都能按预期工作。问题是，通常这些组件会与系统的其他部分（例如数据库、外部服务或其他类）进行交互，这会带来随机性、复杂性和依赖性，从而使测试变成一场噩梦。

这意味着我们要用受控的、模拟的对象来替换这些外部依赖，这些对象以一种可预测且易于管理的方式“模拟”真实对象的行为。这使得被测单元能够被隔离，从而保证任何失败的测试结果都直接归因于被测代码本身的问题，而不是因为数据库宕机或 API 限流。

代码实战：让我们看看具体的例子

为了更好地理解这些概念，我们将通过 Java 和 Mockito 框架（业界最流行的 Mocking 框架之一）来展示一些实际的代码示例。我们将模拟一个简单的电商场景：用户下订单。

场景设置

假设我们有一个 INLINECODE977c82da，它依赖于 INLINECODEc0331fb0（支付服务）和 INLINECODEb3aaec0d（库存服务）。我们想要测试 INLINECODE9aaf0dcb，而不希望真正地扣款或扣减库存。

示例 1：使用 Mocks 验证行为

在这个例子中，我们关注的是交互验证。我们要确保当用户下单时，系统确实调用了支付服务。

import static org.mockito.Mockito.*;
import org.mockito.Mockito;

// 1. 我们需要先定义接口
class OrderService {
    private PaymentService paymentService;

    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }

    public void placeOrder(String userId, double amount) {
        // 业务逻辑：支付
        paymentService.processPayment(userId, amount);
    }
}

interface PaymentService {
    void processPayment(String userId, double amount);
}

// 2. 测试代码
public class OrderServiceTest {
    public void testPlaceOrder_callsPaymentService() {
        // 创建 Mock 对象
        PaymentService mockPayment = Mockito.mock(PaymentService.class);
        OrderService orderService = new OrderService(mockPayment);

        // 执行被测方法
        orderService.placeOrder("user123", 100.0);

        // 验证：确保 paymentService.processPayment 被调用了一次，且参数正确
        // 这就是 Mock 的核心：检查行为
        Mockito.verify(mockPayment).processPayment("user123", 100.0);
    }
}

代码解析：

在这里，INLINECODE8a9a950b 创建了一个完全空的假对象。如果不进行 INLINECODE8a8d7a3c（打桩），它的方法默认返回空或默认值。关键是最后一行 verify，它充当了测试断言的角色，证明交互确实发生了。

示例 2：使用 Stubs 隔离数据

现在，我们不仅要验证行为，还需要根据支付服务的返回结果来决定订单状态。这时候，我们需要控制支付服务的返回值（比如支付成功或失败）。这就是 Stubbing。

import static org.mockito.Mockito.*;

class OrderService {
    private PaymentService paymentService;

    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }

    public String createOrder(String userId, double amount) {
        boolean isSuccess = paymentService.processPayment(userId, amount);
        if (isSuccess) {
            return "ORDER_CREATED";
        } else {
            return "PAYMENT_FAILED";
        }
    }
}

interface PaymentService {
    boolean processPayment(String userId, double amount); // 注意这里返回 boolean
}

public class OrderServiceTest {
    public void testCreateOrder_withSuccessfulPayment() {
        // 1. 创建 Mock
        PaymentService mockPayment = Mockito.mock(PaymentService.class);
        OrderService orderService = new OrderService(mockPayment);

        // 2. 打桩：告诉 Mock 当调用 processPayment 时，返回 true
        // 这就是 Stub：提供预设数据，绕过真实逻辑
        when(mockPayment.processPayment(anyString(), anyDouble())).thenReturn(true);

        // 3. 执行测试
        String result = orderService.createOrder("user123", 100.0);

        // 4. 验证结果
        assert "ORDER_CREATED".equals(result);
    }
}

深入讲解：

注意 INLINECODE5ec96244 这一行代码。这就是我们在编程定义 Mock 的行为。如果不加这一行，INLINECODE0167f13d 将返回 false（boolean 的默认值），测试就会失败。通过 Stubbing，我们将支付逻辑从测试中剥离出去了。

示例 3：使用 Spies 监控真实对象

有时我们不想完全模拟一个类，而是想使用它真实的逻辑，但同时又想监控它有哪些方法被调用了。或者，我们只想覆盖其中的某一个方法，而其他方法保持原样。这时 Spies 就派上用场了。

import static org.mockito.Mockito.*;

public class EmailService {
    public void sendEmail(String to, String subject) {
        // 真实的发送邮件逻辑，这里可能很慢或涉及外部服务器
        System.out.println("Sending real email to " + to);
    }

    public String getSystemStatus() {
        return "ACTIVE";
    }
}

public class SpyTest {
    public void testSpyExample() {
        // 1. 创建 Spy：基于真实对象进行包装
        EmailService spyEmail = Mockito.spy(new EmailService());

        // 2. （可选）我们可以覆盖（Stub）特定方法的行为
        // 比如我们不想真的发邮件，只想模拟它成功了
        doNothing().when(spyEmail).sendEmail(anyString(), anyString());

        // 3. 调用方法
        spyEmail.sendEmail("[email protected]", "Hello");
        spyEmail.getSystemStatus(); // 这个方法会执行真实逻辑

        // 4. 验证交互
        verify(spyEmail).sendEmail("[email protected]", "Hello");
        
        // 验证真实逻辑的结果
        assert "ACTIVE".equals(spyEmail.getSystemStatus());
    }
}

常见陷阱：

使用 Spy 时要小心。当你使用 INLINECODE61c99b01 语法时，真实的 INLINECODE2c7ffb2b 实际上会被调用一次（这可能导致副作用或空指针异常）。更安全的做法是使用 doReturn().when(spy).method()，这样可以避免调用真实方法。

Mocking 的最佳实践

掌握了基本用法后，让我们讨论一下如何像专业人士一样编写 Mock 测试。

1. 不要 Mock 值对象

如果是一个简单的数据持有者，比如 INLINECODEb0443768 对象或 INLINECODE25b79c0e 对象，不要去 Mock 它。直接 new User("John", 30) 即可。Mock 简单的数据对象会让代码变得冗长且难以阅读。通常我们只 Mock 依赖项，即那些被测类需要交互的外部服务或复杂组件。

2. 谨防“Mock 过度”

Mock 的越多，测试就越脆弱。如果你 Mock 了被测类的每一个细节，一旦你重构内部实现（即使外部行为没变），测试就会失败。好的测试应该关注行为，而不是实现细节。

  • 坏实践：验证私有方法是否被调用了（通常需要使用 PowerMock 等高级工具，这通常意味着设计有问题）。
  • 好实践：验证公开的 API 调用是否产生了正确的结果或触发了正确的副作用。

3. 命名清晰

在测试中，变量名非常重要。不要叫 INLINECODEdaa95406 或 INLINECODEe521e786。

  • 推荐：INLINECODEbdd5ca7d，INLINECODEf1dc438c，fakeInMemoryDatabase。

4. 性能优化

虽然 Mocked 的对象通常比真实对象快，但 Mock 框架本身（如通过动态代理实现）也有开销。如果在一个循环中创建成千上万个 Mock 对象，测试速度会显著下降。此外，尽量在 @Before 方法中共享常用的 Mock 设置，而不是在每个测试用例中重复创建。

结论

Mocking 和测试替身是现代软件开发中不可或缺的工具。它们赋予了我们“上帝视角”，让我们能够随意控制时间（延迟）、状态（数据库返回）和结果（外部响应），从而彻底掌控测试环境。

回顾一下，我们学习了：

  • Mocking 是为了隔离依赖和控制环境。
  • Test Doubles 主要分为 Mocks（验证交互）、Stubs（提供数据）、Fakes（简化实现）和 Spies（部分监听）。
  • 实践 中，我们应当谨慎选择 Mock 的对象，关注对外部行为的验证，而不是纠缠于内部实现细节。

通过合理运用这些技术，你不仅可以编写出运行极快的单元测试，还能确保你的代码在面对不可预测的现实世界时，依然坚如磐石。下次当你面对那个难以测试的复杂类时，试着问自己：“我可以 Mock 掉什么？” 祝你编码愉快！

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。如需转载，请注明文章出处豆丁博客和来源网址。https://shluqu.cn/30920.html
点赞
0.00 平均评分 (0% 分数) - 0 票

相关文章美国1G带宽/1T流量高速vps $17.99/年