3. 契约测试概念：什么是契约测试、消费者驱动契约、提供者驱动契约

在微服务与 gRPC 架构中，服务间依赖错综复杂。契约测试（Contract Testing）是一种轻量级的集成测试策略，它不直接启动整个系统，而是通过验证服务间通信的“契约”来确保兼容性。本章将系统讲解契约测试的核心概念、两种驱动模式及其在 gRPC 场景下的应用价值。

3.1 什么是契约测试

契约测试的核心思想是：每个服务间交互都遵循一份明确的“契约”。这份契约定义了请求的格式、字段类型、响应结构、错误码以及交互顺序。契约测试独立验证消费者（Consumer）和提供者（Provider）是否各自遵守了这份约定。

契约测试通常包含三个角色：

• 消费者（Consumer）： 调用远程服务的客户端，例如一个 Go Web 服务调用另一个 gRPC 服务。
• 提供者（Provider）： 暴露远程服务的服务端，例如一个 gRPC 服务。
• 契约（Contract）： 消费者与提供者之间达成的交互协议，通常以 JSON/YAML 或 protobuf 描述。

3.2 消费者驱动契约（Consumer-Driven Contract, CDC）

消费者驱动契约是目前最主流的模式。其核心思想是：由消费者定义契约，提供者验证自己是否满足消费者的期望。消费者根据自身业务需求，编写对提供者接口的调用期望，生成契约文件；提供者则运行契约验证套件，确保自己的实现与所有消费者的契约一致。

CDC 的典型工作流程如下：

1. 消费者编写测试，定义对提供者接口的调用（请求参数、期望响应）。
2. 测试运行后，生成一份契约文件（如 Pact 格式的 JSON）。
3. 消费者将契约文件发布到契约仓库（如 Pact Broker）。
4. 提供者从仓库拉取所有消费者的契约，运行验证测试。
5. 验证通过则部署提供者；验证失败则阻止部署，并通知消费者协商修改。

3.3 提供者驱动契约（Provider-Driven Contract, PDC）

提供者驱动契约是 CDC 的逆向模式。在这种模式下，由提供者定义契约，消费者必须按照提供者发布的契约来调用。提供者先定义好接口规范（如 protobuf 文件），消费者只能使用提供者允许的请求参数和响应格式。

PDC 的典型工作流程：

1. 提供者设计并发布接口契约（如 .proto 文件）。
2. 消费者根据契约生成客户端代码，并实现调用逻辑。
3. 提供者运行契约测试，验证自己的实现是否满足契约定义。
4. 消费者运行自己的测试，验证自己是否正确使用了契约。
5. 任何一方违反契约，都会导致集成失败。

3.4 CDC 与 PDC 对比

3.5 契约测试在 gRPC 中的实践价值

gRPC 使用 protobuf 作为接口定义语言（IDL），天然具备契约属性。但仅仅有 .proto 文件并不等于契约测试。契约测试在 gRPC 场景下带来以下核心价值：

• 早期发现问题： 在部署前即可发现消费者与提供者之间的协议不匹配，避免线上故障。
• 独立部署能力： 消费者和提供者可以独立开发、测试、部署，只要契约不变，双方互不阻塞。
• 回归防护： 当提供者修改接口时，契约测试能快速反馈是否破坏了现有消费者的调用。
• 文档即测试： 契约文件本身就是一份可执行的文档，比静态文档更可靠。

3.6 契约测试 vs 其他测试类型