Pact 契约测试是什么
Pact 属于消费者驱动契约测试:消费方为每个交互生成契约文件,提供方用契约回放做验证;契约经 Broker 发布与比对,避免双方对接口的假设脱节。它关注约定一致性,不覆盖完整业务流程与性能——与端到端测试互补,而不是替代。
基本信息
| 角色 | 消费者(定义契约)、提供方(回放验证) |
|---|---|
| 契约工件 | JSON 契约文件,含请求与期望响应 |
| 状态准备 | provider state 支撑数据已存在等前置条件 |
| 发布枢纽 | Broker 管理契约版本与验证结果 |
| 验证时机 | 提供方 CI 对所有消费方契约逐条回放 |
| 边界 | 不覆盖业务流程正确性与性能 |
| 消费者时机 | 本地运行生成契约,CI 发布到 Broker |
消费者侧示意
消费者侧示意
pact.addInteraction({
state: 'user exists',
uponReceiving: 'a request for user 1',
withRequest: { method: 'GET', path: '/users/1' },
willRespondWith: { status: 200 },
});
// 契约经 Broker 发布;提供方 CI 拉取并逐条验证典型使用场景
- 微服务协作:消费方与提供方独立发布时保证接口不破。
- 前后端分离:前端定义契约,后端回放验证。
- 版本发布:契约验证接入发布流水线,破坏即拦截。
- 重构保护:提供方改内部实现,只要契约满足即安全。
- 联调替代:减少环境必须齐备才能联调的依赖。
- 历史追溯:Broker 保留契约演进记录,定位破坏时间点。
- 变更协商:契约变更先双方沟通再更新版本。
- 兼容矩阵:多版本契约并存时,提供方按版本逐条验证。
- 版本标记:契约定版打上版本与分支标签,回溯定位更快。
契约只在本地验证、未接入发布流程,漂移照旧出现。
契约描述过细(字段顺序与内部结构),提供方重构会被误判为破坏。
provider state 要落到可执行的准备脚本,而不是文档描述。
契约文件进版本库或 Broker 管理:人工传阅容易丢版本。