4. 契约测试工具选型：Pact、Spring Cloud Contract、WireMock 对比分析

在契约测试实践中，工具选型直接影响团队协作效率、测试维护成本与 CI/CD 集成难度。当前主流方案为 Pact、Spring Cloud Contract (SCC) 与 WireMock，三者设计哲学与适用场景差异显著。本章从契约驱动模式、Mock 隔离机制、环境配置复杂度三个维度进行系统对比。

4.1 核心设计理念对比

4.2 契约生命周期与 Mock 隔离机制

三种工具在契约生成、存储、验证阶段的 Mock 隔离策略差异明显，直接影响环境配置复杂度。

4.2.1 Pact：消费者驱动 + Pact Broker 集中管理

• 契约生成：消费者测试中通过 @Pact 注解定义交互，测试运行时自动生成 JSON 格式 Pact 文件。
• Mock 隔离：消费者侧使用 Pact JVM 提供的 Mock 服务端，完全隔离真实生产者。
• 契约存储：Pact 文件上传至 Pact Broker，支持版本化、标签化（如 prod、test）。
• 验证触发：生产者通过 @PactVerification 拉取最新契约并验证，结果回传 Broker。

// 消费者测试示例（Pact JVM）
@Pact(consumer = "order-service", provider = "payment-service")
public V4Pact createPact(PactDslWithProvider builder) {
    return builder
        .given("用户账户余额充足")
        .uponReceiving("支付请求")
            .path("/api/payments")
            .method("POST")
            .body(newJsonBody(body -> {
                body.stringType("userId", "u-001");
                body.decimalType("amount", 99.99);
            }).build())
        .willRespondWith()
            .status(200)
            .body(newJsonBody(body -> {
                body.stringType("transactionId", "txn-abc123");
            }).build())
        .toPact(V4Pact.class);
}

4.2.2 Spring Cloud Contract：生产者驱动 + Stub Runner

• 契约定义：在生产者项目中编写 Groovy/Java DSL 契约文件，存放于 src/test/resources/contracts。
• Mock 隔离：生产者测试自动生成 WireMock stub JSON，消费者通过 Stub Runner 启动嵌入式 Mock 服务。
• 契约存储：契约与 stub 可发布到 Maven 仓库（Nexus/Artifactory），消费者通过依赖引入。
• 验证触发：生产者测试验证契约与实现一致性，消费者使用 stub 进行集成测试。

// 生产者契约定义（Groovy DSL）
Contract.make {
    description "支付接口成功响应"
    request {
        method POST()
        url "/api/payments"
        body([
            userId: $(consumer(regex('[a-z]+-[0-9]+'))),
            amount: $(consumer(regex('[0-9]+\\.[0-9]{2}')))
        ])
        headers {
            contentType applicationJson()
        }
    }
    response {
        status 200
        body([
            transactionId: $(producer(regex('[a-z]+-[0-9a-f]+')))
        ])
        headers {
            contentType applicationJson()
        }
    }
}

4.2.3 WireMock：无契约 + 手动 Mock 定义

• Mock 定义：通过 JSON 映射文件或 Java API 手动配置请求匹配与响应。
• Mock 隔离：独立进程或嵌入式运行，支持记录（Record）真实 API 响应后回放。
• 契约存储：无内置契约仓库，stub 文件通常存放在测试资源目录或版本控制中。
• 验证触发：无自动验证机制，需结合外部断言或契约文件手动比对。

// WireMock Java API 定义 stub
stubFor(post(urlEqualTo("/api/payments"))
    .withHeader("Content-Type", equalTo("application/json"))
    .withRequestBody(matchingJsonPath("$.userId"))
    .willReturn(aResponse()
        .withStatus(200)
        .withHeader("Content-Type", "application/json")
        .withBody("{\"transactionId\": \"txn-abc123\"}")));

4.3 环境配置复杂度对比

以下表格从环境搭建、Mock 服务管理、CI/CD 集成三个维度评估配置工作量：

4.4 选型决策流程

以下 SVG 图展示基于团队规模、契约复杂度与 CI/CD 成熟度的选型决策路径：

4.5 综合推荐场景

4.6 环境配置实践建议

• 统一 Mock 端口管理：无论使用哪种工具，在 CI 环境中应使用随机端口（如 0 或 @LocalServerPort），避免并行构建冲突。
• 契约文件版本化：Pact 文件或 SCC stub 应纳入版本控制或制品仓库，确保不同环境使用一致版本。
• Mock 隔离与真实环境切换：通过 Spring Profile 或环境变量控制 Mock 服务地址，开发环境使用 Mock，集成测试环境切换为真实服务。
• 契约验证自动化：将契约验证步骤加入 CI 流水线，Pact 使用 can-i-deploy，SCC 使用 Maven 插件，WireMock 配合自定义断言脚本。