Cyanix Blog

切换主题

Mock 的使用场景 ​

字数
1567 字
阅读时间
7 分钟

在编写自动化测试时，mock 的使用应该根据测试的目的进行权衡和取舍。通常可以根据以下几方面来决定何时使用 mock、何时依赖实际的组件或服务：

1 单元测试（Unit Test） ​

单元测试的目标是隔离测试代码中的某一小块逻辑（通常是类或方法），确保它的行为符合预期。在这种测试中，外部依赖（如数据库、文件系统、网络服务等）会引入不确定性，导致测试的复杂性和不稳定性增加。因此，单元测试中应优先使用 mock。

适合使用 mock 的场景：

  • 外部依赖存在时：你的代码依赖于数据库、文件系统、第三方 API、消息队列等。使用 mock 来模拟这些外部依赖，确保你只测试代码的业务逻辑，而不涉及外部资源。
  • 依赖不容易控制时：比如一个返回随机结果的服务，或一个时间敏感的外部系统（如定时任务系统）。
  • 加快测试速度：不依赖外部资源（如数据库或网络）的测试运行更快，mock 对象可以显著缩短测试时间。

例子：一个依赖数据库的服务，通常在单元测试中会 mock 掉数据库查询方法。

java
@Test
public void testGetUserRole() {
    // 模拟数据库服务的行为
    when(databaseService.findUserById(1)).thenReturn(new User(1, "admin"));

    // 调用业务逻辑
    String role = userService.getUserRole(1);

    // 验证结果
    assertEquals("admin", role);
}

2 集成测试（Integration Test） ​

集成测试的目标是验证多个模块之间的协作是否正确。这里的模块不仅包括代码模块，还包括外部资源（如数据库、REST 服务、文件系统等）。集成测试通常比单元测试更全面，涉及实际的依赖。

适合避免使用 mock 的场景：

  • 验证实际依赖的交互：如果你想确保代码能正确与数据库、网络服务等外部资源进行交互，应避免使用 mock。你可以在测试时使用实际的依赖，比如使用内存数据库（如 H2、SQLite）或 Docker 中的测试容器。
  • 测试复杂业务流程：如果你的代码涉及多个系统的交互，可能需要在集成测试中真实地测试整个流程，而不是模拟依赖。

例子：一个集成测试可能会实际连接数据库来验证 CRUD 操作的正确性。

java
@SpringBootTest
public class UserServiceIntegrationTest {

    @Autowired
    private UserService userService;

    @Autowired
    private DatabaseService databaseService;

    @Test
    public void testGetUserRoleFromDatabase() {
        // 插入实际的用户数据
        User user = new User(1, "admin");
        databaseService.saveUser(user);

        // 调用业务逻辑
        String role = userService.getUserRole(1);

        // 验证结果
        assertEquals("admin", role);
    }
}

在这种情况下，DatabaseService 没有被 mock 掉，而是使用真实的数据库连接和查询。这种测试提供更高的可靠性，因为它涵盖了从数据库访问到业务逻辑的完整流程。

3 取舍的原则 ​

在选择是否使用 mock 时，可以参考以下几个原则：

3.1 使用 Mock 的场景 ​

  • 关注逻辑，不涉及外部依赖：你只想测试某个类或方法的核心业务逻辑，而外部依赖可以忽略。
  • 避免复杂性：如果外部依赖增加了测试的复杂性，尤其是在无法控制其行为（如第三方 API 返回的不稳定数据），使用 mock 会使测试更可控。
  • 提高测试速度：如果外部依赖会导致测试速度下降（如网络请求或磁盘操作），mock 可以大幅提升测试效率。
  • 模拟极端场景：测试某些难以在实际系统中复现的场景，比如数据库超时、网络故障，mock 可以轻松模拟这些情况。

3.2 避免 Mock 的场景 ​

  • 验证实际交互：如果需要测试代码与外部资源的实际交互（如数据库、消息队列、REST API），集成测试中应避免使用 mock。
  • 确保系统的正确性：在关键的业务流程中，为了确保系统整体的稳定性和正确性，通常会避免过多使用 mock，反而会连接真实的资源进行验证。
  • 最终验收测试：在系统的最终阶段，通常会进行端到端（E2E）测试，模拟用户的真实操作流程。这时应避免使用 mock，确保系统所有组件协同工作良好。

4 最佳实践 ​

  • 单元测试尽量使用 mock，集成测试尽量避免 mock：单元测试要尽量保持独立性、快速、可控，而集成测试则应关注系统各部分的协同工作。
  • 测试覆盖面平衡：单元测试可以快速覆盖大部分代码路径，而集成测试则确保实际依赖和模块之间的集成点正确无误。
  • 混合使用单元测试和集成测试：对于关键业务逻辑，既可以使用 mock 进行单元测试，也可以通过实际依赖来进行集成测试，从不同层次上确保系统的健壮性。

5 总结 ​

  • mock 适用于单元测试，通过隔离外部依赖，使测试更加独立、可控和高效。
  • 集成测试 则应尽量避免 mock，确保测试覆盖实际的依赖和交互。
  • 根据测试的目标和场景合理取舍 mock 的使用，混合使用单元测试和集成测试，确保整个系统的稳定性和可靠性。