契约测试Contract Testing
你可能会说
后端把接口字段改名以后，前端总是到联调或上线才坏，能不能在合并代码前就指出哪个约定被破坏了？
记录调用方真正依赖的请求与响应约定，再验证提供方实际行为是否兼容的自动化测试。例如用户资料页读取 avatar_url 和 nickname。前端的调用方测试先记录这次请求和最小响应要求，后端的提供方验证再用真实响应与它比对；若后端把 avatar_url 改成 avatar，持续集成（CI）会在合并前指出缺失字段。它检查服务之间能否按约定沟通，不证明完整页面、网络环境或业务计算都正确。
也常被叫作Contract Test接口契约测试契约校验
契约测试如何验证调用方与提供方的一致性
api.service.local/v1/users/42调用方记录真实依赖资料页实际读取 →最小响应契约
const avatar = user.avatar_url const name = user.nickname
GET /v1/users/42 → 200
{
"avatar_url": "string",
"nickname": "string"
}↳契约只记录页面真正读取的字段；后端仍可返回其他数据。
一个字段改名怎样在上线前被拦住
失败前：双方只靠口头约定：用户资料页读取 avatar_url 显示头像，后端重构时却把它改成 avatar。后端自己的单元测试仍可能通过，因为它不知道前端依赖旧字段；问题通常要到联调或发布后才暴露。
补入契约并让提供方反馈：前端用一次真实请求写下最小约定：状态码成功，响应里必须有 id、avatar_url 和 nickname，并注明需要的类型。后端在持续集成中重放场景；若字段缺失，检查应指出缺少 avatar_url 并阻止不兼容修改合并。Pact 是常见实现工具之一，不是契约测试本身的同义词。
改善证据：先确认会失败，再恢复兼容：验收时先故意把 avatar_url 改名，确认检查失败；再恢复旧字段或提供兼容转换，确认检查通过。这样证明测试确实能拦住这次破坏，而不只是多了一条永远通过的脚本。
你可以这样告诉 AI Agent
我们前端依赖 GET /v1/users/:id 返回 id、avatar_url 和 nickname。请先根据前端真实读取的字段补一条调用方契约，再在后端 CI 中验证真实响应。验收时故意把 avatar_url 改成 avatar，确认 PR 明确提示缺少 avatar_url 且不能合并；恢复兼容字段后再确认检查通过。
接下来学什么
延伸阅读 · 权威出处
快速练习