测试替身
Test Double
中级通用测试替身（Test Double）是在测试中代替真实依赖的对象，由我们控制它的返回结果或记录它收到的调用。它让你不用真的请求支付服务，也能检查订单代码在付款成功或失败时怎么处理。
你可能会说：「我想测订单逻辑，但不想每次都真的调用支付接口，还想确认代码传了什么参数。」
动手看看下单支付的测试替身
1
先让支付替身预设返回成功。它由测试控制，这次不会真的请求支付服务。
要点测试替身帮你隔开了什么？
- 1
替换的是依赖不是被测逻辑
测订单创建时，订单代码仍然要真实运行；你只把它调用的支付接口换成可控对象。因为测试目标是订单如何处理支付结果，所以替身不该替订单作决定。
- 2
预设结果用来覆盖不同分支
你可以让替身这次返回支付成功，下次返回支付失败，再检查订单状态是否正确。这样测试不用等待外部服务，也不用靠真实支付环境碰运气。
- 3
记录调用用来核对协作
如果重点是确认订单代码有没有传对金额和订单号，替身可以记下收到的参数供测试断言。只在这些调用属于需求的一部分时检查它们；否则测试会和内部实现绑得太紧。
容易混淆的地方
测试替身是代替依赖的对象；测试数据或 Fixture 是给测试准备的输入与环境，例如一笔示例订单，通常不负责回应调用。它也不等于沙箱：支付沙箱仍是一个需要实际连接的服务。替身能验证你写的处理逻辑，却不能证明代码一定能和真实支付接口接通。
什么时候用
适合用
- 测订单服务在支付成功、失败和超时时的处理，又不想让单元测试依赖支付服务是否在线。
- 测 AI 工具收到模型返回的不同内容后如何展示结果，用替身提供可预期的模型响应。
- 想确认通知代码给短信服务传了正确的手机号和内容，但测试时不想真的发短信。
不适合用
- 你要确认应用和真实支付接口的字段、鉴权能否配合工作；这时用沙箱或集成测试。
- 你要验证用户从页面下单到收到结果的完整流程；这时用端到端测试覆盖真实组件间的连接。
- 被测函数只根据输入计算折扣，没有外部依赖；直接传入测试数据并断言结果就够了。
练一练选一个答案，看看解释
你在测订单服务：付款失败时，订单要保持未支付状态。测试不能产生真实扣款，你还想确认传给支付接口的金额。该怎么做？
让 AI 帮你做复制给 AI Agent 直接用
请为订单服务的付款失败分支写测试：用测试替身代替支付接口，预设它返回失败，并记录收到的订单号与金额；断言订单保持未支付且参数正确。保留订单服务的真实逻辑，不发起真实支付请求。