契约测试
Contract Testing
高级通用契约测试（Contract Testing）检查两个服务约定的交互是否仍然成立，例如订单接口是否继续返回前端依赖的状态字段。它解决的是双方各自测试都通过、接在一起却因接口变化而出错的问题。
你可能会说：「前端和后端各自测试都过了，怎么提前发现接口改动会不会把页面弄坏？」
动手看看订单状态改名，发布前能发现吗
1
前端用模拟订单响应跑通页面测试，再生成契约：查询订单时，响应必须包含字符串类型的 status 字段。
要点契约测试在检查什么？
- 1
先找出调用方依赖的约定
你做订单页时，页面可能只依赖订单接口返回编号和状态。契约把请求方式、必要字段及其含义等约定写成可检查的例子，而不是把整个响应原样固定下来。
- 2
再让提供方验证这些约定
前端可以作为调用方，订单服务作为提供方。前端用契约说明自己会怎样调用、期待什么结果；订单服务用自己的实现验证契约。这样后端改接口时，就能较早发现受影响的调用方。
- 3
把发现问题的时间往前移
假设后端把状态字段改名，前端页面还在读旧字段。双方各自的单元测试可能都通过，但契约验证会指出约定已被破坏。我们通常把它放进持续集成，在合并或发布前看到结果。
容易混淆的地方
契约测试关注服务之间约定的交互，不等于端到端测试：它通常不启动整条真实业务链路，所以不能证明用户一定能完成下单。它也不等于单元测试：单元测试可以检查订单服务内部怎么算金额，却未必发现前端依赖的返回字段被删了。
什么时候用
适合用
- 你维护一个网站，前端和后端由不同人修改，想在订单接口字段变更时提前发现页面会受影响。
- 你的后台调用第三方或内部服务，双方独立发布，需要检查调用方依赖的请求和响应约定是否还成立。
- 多个客户端共用同一个接口，提供方准备改版，想在发布前验证已登记的调用方契约。
不适合用
- 你只想检查一个折扣函数在不同输入下算得对不对；用单元测试更直接，没有服务间约定要验证。
- 你想确认用户从登录到支付成功的完整流程能跑通；用端到端测试，因为契约测试不覆盖整条链路。
- 你正在探索新功能，前后端接口还没有稳定的调用关系；先用原型或集成调试摸清交互，再决定固定哪些约定。
练一练选一个答案，看看解释
订单页依赖接口返回的 status 字段。后端准备把它改成 state，两边各自的测试仍然通过。你会怎样提前发现这次改动的影响？
让 AI 帮你做复制给 AI Agent 直接用
请为订单页与订单服务之间增加契约测试：先找出页面实际依赖的请求和响应字段，记录调用方契约，再让服务端实现验证它。把验证接入持续集成，并说明它不能替代哪些端到端检查。