契约测试与 CDC
从服务边界出发，理解 contract testing、消费者驱动契约、provider verification 和事件 schema compatibility 的价值。
#type / synthesis
#status / growing
#tech / dev / test
[!info] related notes
- 所属 MOC: Testing MOC
- 相关概念: 测试设计技术, Monorepo 测试架构, 事件总线下多模块业务原子性问题, 接口规范
- 相关实践: 后端测试, nodejs后端api测试搭建集成测试框架
- 相关工具: Playwright 🚀, postman-cli-and-monitors
契约测试与 CDC
范围
这篇笔记聚焦系统边界，而不是内部业务规则。
为什么要把这些内容放在一起理解
很多跨服务问题不是单个模块逻辑错，而是：
- consumer 和 provider 对协议理解不一致
- 事件 schema 演进破坏了下游
- 大集成测试太慢、太脆、覆盖又不稳定
契约测试的价值，就是把“我真正依赖什么”显式化，然后用更便宜、更稳定的方式持续验证。
contract testing 到底在做什么
它不是在做全链路联调，而是在隔离应用的前提下，检查发送和接收的消息是否符合共享约定。
重点不是“完整模拟对方系统”，而是验证：
- consumer 依赖了哪些字段和行为
- provider 是否仍然满足这些依赖
为什么 CDC 有价值
消费者驱动契约的优势在于，它只验证消费者真正使用的交互，而不是 provider 所有理论能力。
这能减少两类浪费：
- 为了联调而维护大量昂贵的大测试
- 因为 provider 扩展了能力就误以为不会破坏老消费者
一个典型流程
- consumer 先写测试，定义自己的假设
- 测试运行时产出 contract
- provider 在自己的流水线中回放并验证 contract
- 如果 provider 响应与 contract 不匹配，就在集成前发现破坏
适合用在哪些边界
- BFF -> 微服务 HTTP API
- service -> 第三方 provider
- 事件发布者 -> 事件消费者
- SDK -> 后端接口
event schema compatibility
对于事件驱动架构，问题不只是 HTTP request/response，还有：
- 事件名是否变了
- 字段是否删了
- 可选字段是否被错误改成必填
- 枚举是否演进破坏了下游
所以事件 schema compatibility test 本质上也是契约测试的一种边界形式。
它和集成测试的关系
契约测试不能完全替代集成测试。
更合理的分工是：
- contract tests 负责快速验证边界协议是否破坏
- integration tests 负责验证真实系统协作是否成立
两者一起用，才能既快又稳。
最短记忆方式
契约测试不是替代联调，而是把联调前最容易碎的协议假设提前固化并持续验证。