测试一个功能时，代码有时需要调用数据库、邮件服务或第三方接口。如果每次测试都连接真实服务，网络波动、服务状态和外部数据变化都可能影响结果。测试替身是一种常见办法：在测试中用可控制的对象代替真实依赖，让测试集中检查当前关心的行为。
1. 为什么要替换外部依赖
假设一个注册功能在保存用户后会发送欢迎邮件。测试注册逻辑时，如果每次都发送真实邮件，不仅速度慢，还可能误发给别人。把邮件服务换成测试替身后，就可以在不发送邮件的情况下检查注册流程是否发出了发送请求。
2. Stub：提供预先安排的结果
Stub通常用于预先安排依赖的返回结果。例如，让用户查询服务返回一个指定用户，或者模拟“用户不存在”。测试可以借此覆盖不同分支，而不必每次都准备真实数据库。
如果需要测试接口失败后的处理，也可以让Stub返回错误或抛出异常，再检查页面是否显示合适的提示。
3. Mock：检查交互是否符合预期
Mock常用于验证被测代码与依赖之间的交互。例如，在注册成功后，检查邮件发送方法是否被调用、接收人和模板参数是否正确。
这样，注册流程中的邮件发送请求就成了可以直接检查的测试条件。
4. 替身用到什么程度
替身适合让单元测试快速、稳定，并帮助构造正常和异常条件。实际使用时可以分层安排：用替身覆盖关键逻辑和边界，用集成测试检查真实组件之间的连接。
在注册功能中，单元测试检查发送请求和参数，集成测试检查邮件服务接口，实际投递测试检查邮件能否到达测试邮箱。测试记录分别标明这些检查项，方便定位问题和回查结果。
参考：Martin Fowler：Test Double ↗；Google Testing Blog：Test Doubles ↗。