测试替身与测试策略
§1摘要与结论
测试替身是在测试中替换生产对象的任何协作对象的泛称，包括哑元、伪造、桩、监视与模拟五类；按需要隔离的程度选择替身类型，并控制替身的使用范围，是平衡测试速度、确定性与保真度的关键策略。
别名：test double、测试替身、桩与模拟、stub mock fake、测试隔离 | 英文：Test Doubles and Test Strategy | 类型：方法 / practice
§2局部关系图
§3原理 · 为什么
测试替身用于在被测对象与其依赖之间制造受控的接缝，使测试能够隔离目标行为、构造难以真实发生的条件并获得确定性结果。当依赖涉及外部服务、数据库、时间、随机性或尚未实现的组件时，直接使用真实对象会使测试缓慢、不稳定或无法执行；替身通过替换这些依赖，让单元测试保持快速、可重复。不同替身承担的职责不同：哑元只用于填充参数，伪造是以简化实现替代真实逻辑，桩返回预设结果，监视记录调用供事后断言，模拟则预设期望并在交互不符时判定失败。选择替身的依据是测试要验证什么——验证状态结果通常只需桩或伪造，验证对象之间如何协作才需要监视或模拟。替身使用得当能提升测试的可控性与反馈速度，使用不当则会让测试与实现细节绑定，削弱其作为安全网的价值。
§4机制 · 如何运作
测试替身通过在被测对象与协作者之间插入替代实现来运作。隔离的基本单位是接缝——可以在不修改生产代码的前提下替换行为的位置，如接口、注入点或可配置的工厂。桩提供预设的返回值，使测试能够进入特定分支而无需真实计算；伪造提供可工作的简化实现，在保持语义的同时避免昂贵依赖；监视包装真实或替代对象并记录交互；模拟按预期规定调用并验证交互是否发生。验证方式有两类：基于状态的断言检查结果，基于交互的断言检查协作过程。基于交互的测试更精确地约束对象间的消息传递，但也更依赖内部结构，重构时更容易失效。因此替身策略的核心是决定哪些依赖需要隔离、以何种严格程度验证交互，以及在何处保留真实对象以维持保真度。过度替身会把测试变成对实现细节的复述，使测试通过而与真实行为脱节。
§5工程 · 怎么落地
实践中应先确定接缝再选择替身：把外部依赖抽象为接口并通过注入提供，使真实实现与替身在测试中可互换，避免在代码内部硬编码依赖而无法替换。对稳定、快速的纯逻辑依赖可直接使用真实对象，减少不必要的替身；仅对慢、不稳、不可控或尚未实现的依赖使用替身。优先选择构造简单、语义清晰的替身，如返回预设值的桩或简化实现的伪造，谨慎使用严格的交互模拟，因为后者把测试绑定到具体调用序列。用契约测试稳定跨服务接口，使提供者与消费者在替身与真实实现之间保持一致。对涉及状态或事务的行为，尽量在较低层使用伪造或内存实现，把真实集成留给较少量的集成测试。定期审查替身的使用：若某个测试因无关的结构改动频繁失败，说明它与实现耦合过深，应改为基于行为的断言或减少替身。让替身服务于可控与保真之间的平衡，而不是默认对所有依赖一律模拟。对关键外部接口，应让替身与真实实现共享同一契约，并在集成测试中回归验证，缩小二者之间的语义差距。
§6权衡卡
测试替身带来控制与速度，也引入保真度缺失与耦合风险。
替身与被替换的真实对象之间总存在差异，这些差异可能掩盖真实的集成缺陷，使单元测试全绿而系统集成时失败。
严格的交互模拟把测试绑定到对象的调用方式，一旦重构调整内部协作，即使外部行为未变测试也会失败，形成脆弱的测试集，反过来抑制必要的重构。
反过来看，完全不使用替身又会让测试缓慢、依赖外部环境并难以复现失败。
反例之一是过度模拟：测试充满对内部调用序列的期望，成为实现细节的镜像，维护成本高而发现缺陷的能力低。
反例之二是伪造行为与真实实现偏离却不自知，导致测试在虚假的前提下通过。
- 因此替身策略应明确其所验证的假设，用契约测试与少量高保真集成测试补足被替身遮蔽的部分，并控制交互断言的使用，让测试针对可观察行为而非内部协作，从而在隔离与保真之间取得平衡。
- 因此替身的选择应服务于测试要回答的问题，而不是追求形式上的彻底隔离。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7信源与核验
核验结论：替身用于隔离慢或不可控的依赖，过度使用会让测试与实现细节耦合、并且因与真实对象存在差异而掩盖集成缺陷；应控制替身范围并配合契约测试与少量高保真集成测试 [WEB-029]
§8原始关系清单
展开：本节点的全部原始关系边（1 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 依赖关联 | ← MTH-I-03 | 测试驱动开发 E-492 | TDD 单元循环依赖测试替身隔离依赖 |