1. 契约测试概述
1.1 什么是契约测试
契约测试（Contract Testing）是一种介于单元测试与端到端测试之间的集成验证方法，它通过定义并验证服务间交互的“契约”——即接口的输入、输出、状态码、错误码、超时行为等约定——来确保通信双方在独立演进时仍能保持兼容。在微服务架构中，每个服务都由不同团队维护，契约测试充当了“接口法律文件”的角色，任何一方违反契约都会在持续集成阶段被快速捕获。
核心思想： 不启动真实依赖服务，而是通过模拟消费者（Consumer）或提供者（Provider）的期望来验证接口行为。契约一旦生成，双方都必须遵守。
1.2 契约测试的核心价值
| 价值维度 | 说明 | 典型场景 |
|---|---|---|
| 反馈速度 | 秒级运行，无需部署完整环境 | CI流水线中每次提交自动触发 |
| 独立演进 | 消费者和提供者可各自修改，只要契约不变 | 搜索服务升级Redis客户端版本 |
| 错误码断言 | 精确验证错误码、异常消息、状态码 | Redis连接超时返回ERR_TIMEOUT |
| 减少回归 | 接口变更立即暴露不兼容 | 新增必填字段导致消费者崩溃 |
| 文档即测试 | 契约文件自动生成可读的API文档 | Pact Broker中的交互记录 |
1.3 契约测试在微服务中的角色
在微服务架构中，服务间通信通常依赖HTTP/REST、gRPC或消息队列。契约测试位于以下位置：
- 消费者端（Consumer）： 生成期望请求与响应，模拟提供者行为，验证自身能否正确解析响应。
- 提供者端（Provider）： 验证真实接口是否满足消费者契约中的所有期望。
- 契约仓库（Contract Repository）： 存储所有契约文件，支持版本管理和变更通知。
1.4 契约测试与集成测试的区别
很多团队容易将契约测试与集成测试混淆，二者在目标、范围、运行方式和维护成本上有本质区别：
| 对比维度 | 契约测试 | 集成测试 |
|---|---|---|
| 验证目标 | 接口契约是否被双方遵守 | 多个服务组合后功能是否正常 |
| 依赖环境 | 模拟/桩（Mock/Stub） | 真实服务实例（可容器化） |
| 运行速度 | 毫秒～秒级 | 分钟级（启动依赖服务） |
| 错误定位 | 精确到字段/错误码级别 | 模糊，需排查多个服务日志 |
| 维护成本 | 低，契约文件自动生成 | 高，需维护测试环境与数据 |
| 典型工具 | Pact、Spring Cloud Contract | Testcontainers、WireMock |
| Redis错误码场景 | 断言ERR_TIMEOUT、ERR_CONNECTION | 验证Redis集群整体可用性 |
关键区别总结： 集成测试回答“系统能否正常工作”，契约测试回答“接口约定是否被破坏”。在搜索服务中，集成测试会启动真实Redis集群验证搜索功能，而契约测试只验证搜索服务返回的Redis错误码格式是否符合消费者预期。
1.5 契约测试的典型工作流
- 消费者编写期望： 消费者团队定义对提供者接口的请求与预期响应，包括正常数据和错误码。
- 生成契约文件： 工具（如Pact）自动生成JSON/YAML格式的契约文件，上传至契约仓库。
- 提供者验证契约： 提供者团队拉取契约文件，运行验证测试，确保真实接口满足所有期望。
- 持续集成集成： 双方CI流水线均包含契约验证步骤，任何不兼容变更立即失败。
- 错误码断言： 在契约中明确声明Redis错误码（如ERR_TIMEOUT、ERR_NOREPLICAS），提供者必须返回完全匹配的错误码。
常见误区： 契约测试不能替代集成测试。在搜索服务中，契约测试确保Redis错误码格式正确，但无法验证Redis集群在高并发下的真实表现——后者仍需集成测试覆盖。
1.6 本课程中的契约测试定位
在《契约测试中Redis错误码断言：搜索服务接口通信机制》课程中，契约测试将聚焦于：
- Redis错误码的精确断言： 如
ERR_TIMEOUT、ERR_CONNECTION、ERR_NOREPLICAS等，确保搜索服务在Redis异常时返回符合契约的错误码。 - 消费者与提供者解耦： 搜索前端（消费者）不依赖真实Redis，搜索后端（提供者）可独立修改Redis客户端逻辑。
- CI流水线集成： 每次提交自动验证契约，防止错误码变更导致前端解析失败。