绿色测试结果可能掩盖一条缺失规则。在这个示例中，代理受托连接商店与邮件平台。测试服务器接受联系人更新，整齐地返回 200。代理完成任务，测试通过。
真实目标系统却多一条规则：联系人更新要设置自定义属性，必须先声明该属性。测试服务器没有模拟它。绿色结果只证明代理在测试世界里的表现，对真实世界那条缺失规则毫无证明力。
这是模拟的核心交换：它让危险或昂贵的动作可以重复测试，也造出第二个系统，而第二个系统的行为可能逐渐偏离第一个。
替身让动作测试成为可能
要测试会行动的代理，给它目标、环境和可观察的最终状态。关于模拟代理环境的来源讨论在浏览器和知识工作任务中描述这种结构。环境让验证器比较代理留下的状态与已知正确结果。
对于集成，替身可以开放少量目标系统操作：列出字段、创建联系人、更新联系人、读回记录。测试材料中可有一个已声明的 FNAME 字段和一个不存在的 CUSTOM_TIER 字段。测试让代理提出映射，再拒绝在定义 CUSTOM_TIER 前使用它的写入。
替身的好处是每次从同一状态开始。一次只改变一个条件：字段缺失、权限拒绝、模式版本过时、标识符含糊。可以跨模型或提示比较代理的调用顺序及结果状态。
这比纯文字问代理会怎么做更强，因为它测试代理在受控世界里实际调用了什么。
测试材料要保留每次调用前后的状态，而不只是预先写好的响应。如果代理两次创建同一联系人，第二次应暴露你要测试的重复行为。写入后读取字段，也应返回存储状态。否则代理发送一个看似合理的请求就能通过测试，系统却从未发现顺序是否产生预期记录。
保真度也是测试的一部分
合理的反对意见是：“供应商有沙盒，为什么再做一个？”如果沙盒支持需要的案例且能保护数据，就用它。需要确定性重置、故意制造故障，或测试沙盒无法安排的调用时，本地替身才有价值。但它也有维护成本：模拟的每条规则都可能错误或过时。
官方Brevo 联系人 API说明联系人属性必须在账户中存在，与声明类型不符的值会被忽略。如果替身拒绝每个格式错误的值，就与文档中的情况不同，可能让代理期待实际不会到来的错误。
写明替身覆盖哪些供应商行为。对真实 API 或官方测试环境保留一小组契约探针。探针发现差异，就更新替身并加入发现它的案例。模拟是供应商的模型，不是供应商本身的替代品。
时间也要遵守同一原则。每次写入都立刻可见的替身，可能漏掉过早读取的工作流；每次都延迟的替身，可能制造供应商本不会造成的失败。只在时间影响被测决定时模拟它，其他情况标明超出模拟范围。通过测试才有精确含义：该代理在这些被模拟的规则下完成这些动作。
Tajo 的Brevo 连接器指南从商家角度说明同一个现实问题：请求成功，字段却可能缺失。测试只有检查字段，而非只看 HTTP 响应，才有用。
模拟目标系统在被模拟的规则下测试代理。范围有限的预览前，契约探针将这些规则与真实目标系统比较。
从安全彩排走向有限的真实证据
模拟通过后，应在真实目标系统做小范围预览。选几条预期目标状态明确的记录，包含普通记录、缺少可选字段的记录，以及同意状态禁止营销使用的记录。检查目标系统实际存了什么，不要只凭请求内容推断。
模拟数据预览和目标系统检查回答不同的问题。Tajo 的映射预览在不写入目标系统的情况下测试转换规则。下方拟议视图展示下一道边界：即使更新已应用，也还须检查目标系统的状态。保留待检查状态，才不会把排练误当成证据。
写入完成仍需证据
客户同步完成了吗？
写入已应用，验证待进行。
尚未检查目标系统的状态。
同步活动
- 请求已接受
- 更新已应用
- 目标系统检查待进行
示例运行 · 14:32 UTC
已知信息
- 服务商响应
- 已接受
- 写入结果
- 已应用
- 从目标系统回读
- 待进行
调用成功不能证明最终状态。
此拟议布局参考 Tajo 的活动记录。图中增加了验证状态，并不表示目标系统回读功能已经实现。
预览范围要窄，停止条件要清楚。失败应阻止广泛启用，并指出确切差异：字段定义、标识符、类型、许可或时间。通过预览也不能证明未来每条记录都会相同，但能说明今天所选案例的契约有效。
这个顺序区分两个问题。模拟问：“我们控制世界时，代理会遵守设计的规则吗？”真实预览问：“设计的规则适合这个供应商账户吗？”两者不能互相替代。
反向 ETL 指南说明最终任务为何会在许多记录上重复。这种重复会放大模拟契约与真实契约之间留下的任何差异。
先在可重置的世界排练，再检查无法重置的世界。
常见问题
模拟目标系统能测试什么？
它可以测试代理是否选择预期调用、遵守权限、处理已知错误，并在模拟环境内留下预期状态。
它不能证明什么？
它不能证明供应商模型完整。未文档化的行为、时间差和账户专属配置都可能不同。
模拟通过后该做什么？
对实际目标系统运行范围有限的预览或小规模试运行，再检查结果状态，然后才广泛启用。