4. Mock隔离原理：Mock对象与Stub的区别、Mock隔离的动机与粒度
在API接口测试中，Mock隔离是确保测试独立性与可靠性的核心实践。本章深入剖析Mock对象与Stub的本质区别、Mock隔离的三大动机，以及在不同粒度下的隔离策略，帮助你在测试架构设计中做出精准决策。
4.1 Mock对象与Stub的区别
Mock与Stub常被混用，但在测试隔离语境下，二者有明确的职责边界。下表从多个维度进行对比：
| 维度 | Stub（桩） | Mock（模拟对象） |
|---|---|---|
| 核心目的 | 提供预设的返回值，使被测代码能顺利执行 | 验证交互行为，检查方法是否被正确调用 |
| 验证方式 | 不验证调用过程，只关注结果 | 验证调用次数、参数、顺序等交互细节 |
| 状态管理 | 通常无状态，每次返回固定数据 | 可记录调用历史，支持行为断言 |
| 典型场景 | 数据库查询、外部API响应模拟 | 消息队列发送、日志记录、权限校验 |
| 测试风格 | 基于状态的测试（State-based） | 基于交互的测试（Interaction-based） |
关键原则：Stub用于“提供数据”，Mock用于“验证行为”。在API测试中，优先使用Stub模拟下游服务响应，仅在需要验证调用协议（如重试、超时、回调）时使用Mock。
以下代码示例展示了Stub与Mock在Java Mockito框架中的典型用法：
// Stub：预设返回值，不关心调用过程
when(userService.getUserById(1001)).thenReturn(new User("Alice"));
// Mock：验证交互行为
Mockito.verify(emailService, times(1)).sendWelcomeEmail("alice@example.com");
4.2 Mock隔离的三大动机
引入Mock隔离并非为了“模拟”而模拟，而是为了解决测试工程中的三个核心痛点：解耦、加速、稳定性。
实践建议：在API测试中，优先对“慢”和“不稳定”的外部依赖（如第三方支付接口、短信网关）实施Mock隔离，而对内部微服务可酌情使用轻量级Stub。
4.3 Mock隔离的粒度
Mock隔离并非“一刀切”，需要根据测试目标和系统架构选择适当的粒度。通常分为三个层级：服务级、方法级、数据级。
4.3.1 服务级隔离
在微服务架构中，服务级隔离是最常见的策略。通过Mock整个下游服务，使被测服务无需依赖其他服务的实际部署。
- 适用场景：跨服务API调用、消息队列消费、外部网关集成
- 实现方式：使用WireMock、MockServer等工具模拟HTTP端点
- 优点：隔离彻底，测试环境搭建简单
- 缺点：粒度较粗，无法覆盖内部逻辑分支
4.3.2 方法级隔离
在单元测试或组件测试中，方法级隔离针对特定类或模块的依赖方法进行Mock。
- 适用场景：DAO层方法、缓存操作、日志记录
- 实现方式：使用Mockito、EasyMock等框架创建动态代理
- 优点：精细控制，可验证复杂交互逻辑
- 缺点：与实现耦合度高，重构时维护成本大
4.3.3 数据级隔离
数据级隔离关注测试数据的独立性与可重复性，通过Mock数据源或数据工厂实现。
- 适用场景：数据库查询、缓存命中/未命中、分页数据
- 实现方式：内存数据库（H2）、数据工厂模式、JSON/CSV数据文件
- 优点：测试数据可控，避免脏数据污染
- 缺点：需要维护大量测试数据，数据一致性验证复杂
常见误区：不要在所有测试中都使用方法级Mock。过度Mock会导致测试与实现高度耦合，重构时测试大面积失效。优先选择“最外层”的隔离粒度——能用服务级Mock解决的问题，就不要深入到方法级。
4.4 隔离策略选择矩阵
以下矩阵帮助你在不同测试场景中快速选择隔离粒度：
| 测试类型 | 推荐粒度 | 隔离对象 | 典型工具 |
|---|---|---|---|
| API契约测试 | 服务级 | 下游微服务、第三方API | WireMock, Pact |
| 业务逻辑单元测试 | 方法级 | DAO、缓存、消息发送 | Mockito, JMockit |
| 数据边界测试 | 数据级 | 数据库、Redis、文件系统 | H2, Embedded Redis |
| 端到端测试 | 不隔离（真实依赖） | — | — |
核心结论：Mock隔离的本质是“控制变量法”——通过替换不可控的外部依赖，使测试结果仅由被测代码决定。选择隔离粒度时，遵循“最小必要”原则：在保证测试独立性的前提下，选择最粗的隔离粒度，以降低维护成本。