按依赖类型选择验证替代方案

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

订单模块计算总价、写数据库并调用第三方支付。要测试支付失败时订单保持待支付，不能只模拟每个内部函数然后断言它们被调用。先了解依赖所有权及替身能力。

具体做法

列出四类依赖：进程内计算直接经模块接口测试；可本地替代的存储使用兼容替身并保留实际读写逻辑；自有远端服务在边界定义端口，注入生产传输与测试适配器；真正外部支付注入可控模拟适配器。通过创建/查询订单接口断言状态，不暴露内部函数供测试调用。记录替身与生产的语义差异并安排相应契约检查。

反例

为测试订单支付失败，模拟计算、保存、状态更新和支付全部函数；只断言每个函数调用次数。

改进写法

经订单模块接口创建总价100的订单，用本地数据库替身和支付失败适配器执行付款，再查询订单。断言仍为待支付且金额100；不对内部函数调用顺序做断言。注明该测试未验证真实支付网络和生产数据库差异。

为什么这样改

替代方案应围绕依赖边界，而不是围绕每个实现细节。保留模块内逻辑和可行的存储路径，能让可见行为测试在内部重构后继续有效。

如何验证

教学检查矩阵：支付成功适配器使订单已支付；明确拒绝使其待支付；超时按产品契约成为待确认或待支付，不能擅自假定未扣款。核对数据库可查询结果；更换内部函数拆分后这些断言应保持有效。

适用边界

替身不能证明生产事务、锁、网络重试或第三方契约一致。只有确有生产和测试两种适配需求时才增加端口。旧测试是否删除取决于它们提供的行为覆盖，不能因为来源建议替换就机械删除。