1. 课程导论：什么是契约测试、为什么需要契约测试、契约测试与集成测试的区别
1.1 什么是契约测试
契约测试（Contract Testing）是一种介于单元测试与端到端测试之间的微服务验证方法。它不直接验证整个系统的行为，而是验证服务之间交互的“约定”——即调用方（Consumer）期望的请求格式与被调用方（Provider）承诺的响应格式是否一致。
在微服务架构中，每个服务都由不同团队独立演进。服务间的通信依赖明确的接口规范（如 REST API、gRPC 或消息队列 Schema）。契约测试的核心思想是：将接口规范转化为可执行的断言，并在持续集成流水线中自动校验。
核心定义： 契约测试是一种轻量级的、面向接口的测试策略，通过 Consumer-Driven Contracts（CDC）或 Provider-Driven Contracts 来验证服务间通信的兼容性，确保双方对接口的理解一致。
1.2 为什么需要契约测试
微服务架构带来了独立部署、技术异构等优势，但也引入了服务间依赖的复杂性。传统测试策略在以下场景中暴露出明显短板：
| 场景 | 问题 | 契约测试的解决方案 |
|---|---|---|
| Provider 修改响应字段 | Consumer 未感知，上线后解析失败 | Consumer 契约在 CI 中自动验证 Provider 的响应结构 |
| Consumer 发送新请求参数 | Provider 未实现，返回 400/500 | Provider 契约验证 Consumer 的请求是否在支持范围内 |
| 多版本共存 | 旧 Consumer 与新 Provider 不兼容 | 契约版本化，支持向后兼容性校验 |
| 集成环境不稳定 | 端到端测试频繁因环境问题失败 | 契约测试可在本地或 CI 中独立运行，不依赖完整环境 |
契约测试的核心价值在于：将接口兼容性验证左移，在代码合并前发现破坏性变更，避免问题流入集成环境或生产环境。
实践建议： 在微服务数量超过 5 个、或服务由不同团队维护时，契约测试的投资回报率（ROI）显著高于传统集成测试。建议从核心调用链路的服务间契约开始落地。
1.3 契约测试与集成测试的区别
契约测试与集成测试虽然都关注服务间交互，但在测试范围、运行方式、反馈速度等方面存在本质差异。下表从多个维度进行对比：
| 对比维度 | 契约测试 | 集成测试 |
|---|---|---|
| 测试范围 | 仅验证接口契约（请求/响应结构、状态码、头信息） | 验证服务间真实通信，包括网络、中间件、数据库等 |
| 运行环境 | 本地、CI 环境，无需部署完整服务 | 需要集成环境或 Staging 环境，服务需全部启动 |
| 反馈速度 | 秒级，每次代码提交均可运行 | 分钟级至小时级，依赖环境准备和部署 |
| 故障定位 | 精确到接口字段级别 | 需要排查网络、配置、数据等多方面因素 |
| 维护成本 | 低，契约文件轻量，自动生成 | 高，需要维护测试数据、环境配置、Mock 服务 |
| 覆盖能力 | 覆盖所有 Consumer 的调用场景 | 通常只覆盖核心业务路径 |
从测试金字塔的角度看，契约测试位于单元测试之上、端到端测试之下，填补了传统测试策略中“接口兼容性验证”的空白。集成测试仍然重要，但应聚焦于验证非功能性需求（如超时、重试、熔断），而非重复验证接口结构。
常见误区： 契约测试不能完全替代集成测试。契约测试只验证接口格式，不验证业务逻辑正确性、数据一致性、性能等。两者应互补使用：契约测试用于快速反馈接口兼容性，集成测试用于验证真实环境下的端到端行为。
1.4 契约测试在微服务架构中的位置
下图展示了契约测试在典型微服务架构中的定位：它作为 Consumer 与 Provider 之间的“验证层”，在 CI 流水线中独立运行，不依赖集成环境。
1.5 契约测试的核心工作流程
一个标准的契约测试流程包含以下步骤：
- Consumer 定义契约： Consumer 团队根据业务需求，编写对 Provider 接口的期望（请求参数、响应结构、状态码）。
- 契约发布： 将契约文件（如 Pact 文件）上传至契约仓库（如 Pact Broker）。
- Provider 验证契约： Provider 团队在 CI 中拉取最新契约，运行验证套件，检查实际接口是否满足契约要求。
- 结果反馈： 验证通过则允许合并代码；验证失败则阻断流水线，并通知相关团队。
- 版本管理： 支持多版本契约共存，确保向后兼容性。
关键成功因素： 契约测试的落地需要 Consumer 和 Provider 团队共同维护契约文件，并建立“契约即文档、契约即测试”的协作文化。推荐使用 Pact、Spring Cloud Contract 等成熟框架。