📚 课程目录第4章契约测试基础

4. 契约测试基础：消费者驱动契约（CDC）概念、Pact框架核心、契约版本管理

在微服务架构中，服务间依赖错综复杂，传统集成测试往往需要部署全链路环境，成本高且反馈慢。消费者驱动契约（Consumer-Driven Contract, CDC）提供了一种轻量级、可并行验证的替代方案。本章将系统讲解CDC的核心思想、Pact框架的实现机制以及契约版本管理的工程实践。

4.1 消费者驱动契约（CDC）概念

CDC的核心思想是：由服务的消费者（Consumer）定义其对提供者（Provider）API的期望，并将这些期望固化为契约。提供者只需验证自己是否满足所有消费者的契约，即可保证兼容性，无需为每个消费者单独部署集成环境。

对比维度	传统集成测试	消费者驱动契约（CDC）
测试触发方	提供者或测试团队	消费者
环境依赖	全链路集成环境	Mock服务 + 契约验证
反馈速度	慢（分钟级~小时级）	快（秒级~分钟级）
变更影响范围	需回归全链路	仅验证受影响的消费者契约
维护成本	高（环境搭建、数据准备）	低（契约文件 + CI流水线）

  关键原则：CDC不是替代端到端测试，而是将集成验证左移，在开发阶段尽早发现接口不兼容问题。它特别适用于一个提供者被多个消费者调用的场景。

4.2 Pact框架核心

Pact是目前最成熟的CDC实现框架，支持多种语言（Java、JavaScript、Python、Go等）。其核心工作流程分为三个阶段：契约生成、契约发布、契约验证。

Pact核心概念：Pact文件是一个JSON格式的契约文件，包含消费者名称、提供者名称、交互列表（请求与期望响应）。每个交互使用匹配器（Matcher）定义字段规则，而非固定值，从而允许提供者在满足规则的前提下灵活调整实现。

4.2.1 消费者端：契约生成

消费者在单元测试中，使用Pact框架Mock提供者服务，定义期望的请求和响应。测试通过后，Pact自动生成一个JSON契约文件。

// Java示例：消费者端定义契约
@Pact(consumer = "OrderService", provider = "PaymentService")
public V4Pact createPact(PactDslWithProvider builder) {
    return builder
        .given("用户账户余额充足")
        .uponReceiving("发起支付请求")
            .path("/api/payment")
            .method("POST")
            .headers("Content-Type", "application/json")
            .body(new PactDslJsonBody()
                .integerType("userId", 1001)
                .decimalType("amount", 99.99))
        .willRespondWith()
            .status(200)
            .body(new PactDslJsonBody()
                .stringType("transactionId")
                .stringMatcher("status", "success|pending"))
        .toPact();
}

4.2.2 提供者端：契约验证

提供者获取消费者发布的Pact文件，在本地运行验证测试。Pact框架会模拟消费者请求，并断言提供者的实际响应是否符合契约中的匹配规则。

// Java示例：提供者端验证契约
@Provider("PaymentService")
@PactBroker(url = "http://pact-broker:9292")
public class PaymentServicePactTest {

    @TestTemplate
    @ExtendWith(PactVerificationInvocationContextProvider.class)
    void verifyPact(PactVerificationContext context) {
        context.verifyInteraction();
    }

    @BeforeEach
    void setUp(PactVerificationContext context) {
        // 启动提供者服务（Mock或真实实例）
        context.setTarget(new HttpTestTarget("localhost", 8080));
    }
}

4.2.3 Pact工作流SVG图

下图展示了Pact框架从消费者契约生成到提供者验证的完整闭环流程：

4.3 契约版本管理

随着微服务迭代，契约本身也需要版本化管理。Pact Broker提供了契约存储、版本对比、兼容性验证和发布标记等能力。版本管理的关键在于确保消费者和提供者始终使用兼容的契约版本。

4.3.1 版本管理核心策略

语义化版本（SemVer）：消费者和提供者各自维护版本号，契约文件通过标签（Tag）关联到具体版本。
分支环境隔离：使用Git分支名作为Pact Broker的标签（如 feature/payment-v2），避免开发中的契约影响主干。
兼容性验证矩阵：提供者验证时，需验证所有已发布且未过期的消费者契约版本，确保向后兼容。
契约过期与清理：通过设置 pactbroker.provider.version 和 pactbroker.consumer.version，结合CI流水线自动清理旧版本契约。

4.3.2 版本管理对比表

管理维度	传统方式（无版本管理）	Pact Broker版本管理
契约存储	本地文件或共享目录	中央Broker + 版本化存储
版本关联	手动维护映射关系	自动关联消费者/提供者版本
兼容性验证	全量回归，无差异对比	按版本标签验证，支持差异分析
发布控制	无控制，易覆盖	支持标记（Tag）和发布审批
回滚能力	困难，需手动恢复文件	支持按版本回滚，保留历史记录

4.3.3 契约版本管理SVG图

下图展示了基于Pact Broker的契约版本管理架构，包括多消费者、多版本、标签隔离和验证矩阵：

常见陷阱：不要将契约文件直接放在代码仓库中手动管理。这会导致版本混乱、合并冲突和验证遗漏。始终使用Pact Broker或兼容的中央存储服务，并通过CI/CD流水线自动化契约的发布与验证。

4.4 本章小结

CDC核心：消费者定义期望，提供者验证满足，实现解耦和左移测试。
Pact框架：提供消费者端Mock生成契约、Broker中央存储、提供者端回放验证的完整工具链。
版本管理：通过Pact Broker的标签、版本号和兼容性矩阵，确保多服务多版本间的契约一致性，支撑持续交付。