用途
契约测试验证的是消费者与提供者之间的“约定”，而不是任何一方的内部行为。消费者定义自己期望从提供者那里得到什么，提供者验证自己能够满足这些期望。该技能把契约测试同时视为一种设计纪律和测试技术，要求先应用自动测试的通用原则，再叠加契约范围的特殊规则。
主要能力
- 指导在什么情况下使用契约测试：两个服务由不同团队开发且必须保持兼容；需要在部署前发现破坏性 API 变更；需要验证消费者只使用提供者实际提供的能力；需要校验已发布的 schema（OpenAPI、Avro、Protobuf、JSON Schema）与实际用法是否一致。
- 明确不适用场景：验证服务内部业务逻辑应使用单元测试或集成测试；验证两个服务是否产出正确的最终用户结果应使用端到端测试。
- 提出四条核心原则：消费者定义契约；契约是发布制品（版本化文件或注册表条目，在消费者与提供者之间共享，提供者针对已发布契约执行验证，而非消费者的测试源码）；两端都要验证（消费者编写期望、生成契约制品并发布到 broker 或仓库，提供者拉取契约制品、执行提供者验证并发布验证结果，双方都通过才算完整）；契约保持窄范围（只捕获消费者实际使用的字段、状态码和消息键，避免断言完整响应体）。
- 给出契约测试中的 AAA 结构：消费者侧描述交互、让消费者代码对 mock 提供者运行、断言消费者正确处理响应并产生契约制品；提供者侧启动真实提供者、回放契约制品中的每个交互、断言提供者响应满足契约中的每项期望。
- 提供契约坏味道检查清单：契约过宽、缺少版本策略、消费者编码提供者逻辑、缺少提供者验证步骤、双方修改同一契约文件、schema 漂移未被发现，并给出对应修正方向。
使用方式
按技能内容，可先在消费者侧编写只覆盖实际使用部分的期望，并生成、发布契约制品；再在提供者侧拉取该制品，执行提供者验证，并将验证接入提供者的 CI 流水线。使用 schema 注册表时，消费者和提供者都针对同一已发布 schema 校验，schema 变更需在部署前提升版本，并使用兼容模式（backward、forward、full）来把关合并。工具选择上，资料只列出常见工具类别而不做指定：消费者驱动契约可用 Pact（多语言）、Spring Cloud Contract；基于 schema 的契约可用 Schemathesis、Dredd、OpenAPI diff 工具；消息/事件契约可用 Pact message pacts、Confluent Schema Registry；GraphQL 契约可用 GraphQL Inspector。具体工具的惯用法需参考团队标准。
适用场景
适用于跨团队服务兼容性保障、部署前破坏性变更检测、消费者对提供者接口使用范围的校验，以及 schema 与实际用法一致性的验证。
限制
契约测试不验证提供者是否“正常工作”，只验证其是否满足消费者期望；若不在 CI 中运行提供者验证，契约会带来虚假信心；若把契约当普通文件手工传递，容易过期，应使用契约 broker 或注册表。资料未提供该技能的具体安装命令、收费方式、价格或平台信息。