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

4、契约测试基础：契约测试与单元测试、集成测试的区别，使用pact-go实现消费者驱动的契约测试

4.1 契约测试的定位与价值

在微服务架构中，服务间依赖关系复杂，传统测试策略难以覆盖接口变更带来的连锁问题。契约测试（Contract Testing）通过定义服务间交互的“契约”，确保消费者（Consumer）与提供者（Provider）之间的通信符合预期，从而在早期发现接口不兼容问题。

  核心定义： 契约测试是一种介于单元测试与集成测试之间的测试方法，它验证服务间交互的“契约”是否被双方遵守，而不需要部署完整的集成环境。

4.2 契约测试 vs 单元测试 vs 集成测试

三种测试方法在目标、范围、执行速度、依赖管理上存在显著差异。下表从多个维度进行对比：

维度	单元测试	契约测试	集成测试
测试目标	验证单个函数/方法逻辑	验证服务间接口契约一致性	验证多个组件协同工作
测试范围	最小代码单元	消费者-提供者交互边界	跨服务/跨系统流程
执行速度	毫秒级	秒级	分钟级或更慢
外部依赖	无（Mock全部隔离）	仅需契约文件或Mock服务	需要真实服务/数据库/中间件
反馈周期	即时	快速（CI中分钟级）	慢（环境准备+部署）
变更敏感度	低（内部重构）	高（接口变更立即暴露）	中（环境问题可能掩盖接口问题）
典型工具	Go testing, testify	Pact, Spring Cloud Contract	Testcontainers, Docker Compose

实践建议： 在Go Web服务中，推荐采用“单元测试 + 契约测试 + 少量集成测试”的测试金字塔。契约测试填补了单元测试与集成测试之间的空白，尤其适合HTTP/REST、gRPC等协议的服务间调用。

4.3 消费者驱动的契约测试（CDC）原理

消费者驱动的契约测试（Consumer-Driven Contract, CDC）是一种由服务消费者定义契约的测试模式。消费者先编写期望的交互契约，提供者验证自己是否满足该契约。这种模式天然适合微服务演进，因为消费者最清楚自己需要什么。

下图展示了CDC的核心流程：

4.4 使用pact-go实现CDC测试

Pact是目前最流行的CDC测试框架，pact-go是其Go语言实现。它支持HTTP和gRPC协议，能够生成JSON格式的契约文件（pact文件），并通过Pact Broker进行共享和验证。

4.4.1 环境准备

# 安装pact-go命令行工具
go install github.com/pact-foundation/pact-go/v2@latest

# 验证安装
pact-go version

# 启动Pact Broker（可选，用于契约共享）
docker run -d --name pact-broker \
  -p 9292:9292 \
  -e PACT_BROKER_DATABASE_URL=postgres://postgres:password@host.docker.internal:5432/pact_broker \
  pactfoundation/pact-broker

4.4.2 消费者端：定义契约并生成pact文件

在消费者服务中，使用Pact DSL定义对提供者API的期望，并生成契约文件。

package consumer_test

import (
    "testing"
    "github.com/pact-foundation/pact-go/v2/consumer"
    "github.com/pact-foundation/pact-go/v2/matchers"
)

func TestUserServiceConsumer(t *testing.T) {
    // 创建Pact Mock服务
    mockProvider, _ := consumer.NewV2Pact(consumer.MockHTTPProviderConfig{
        Consumer: "user-web-app",
        Provider: "user-api-service",
    })

    // 定义交互契约
    mockProvider.
        AddInteraction().
        Given("用户ID 12345存在").
        UponReceiving("获取用户信息的请求").
        WithRequest("GET", "/users/12345").
        WithHeader("Accept", "application/json").
        WillRespondWith(200, func(b *consumer.V2ResponseBuilder) {
            b.Header("Content-Type", "application/json")
            b.Body(consumer.Like(map[string]interface{}{
                "id":       matchers.Integer(12345),
                "name":     matchers.String("张三"),
                "email":    matchers.StringRegex("zhangsan@example.com", `^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`),
                "age":      matchers.Integer(28),
            }))
        })

    // 执行消费者逻辑（调用Mock服务）
    // 实际代码中会调用mockProvider.URL作为API地址
    t.Logf("Mock服务地址: %s", mockProvider.URL)

    // 验证交互并生成pact文件
    if err := mockProvider.WritePact(); err != nil {
        t.Fatalf("生成契约文件失败: %v", err)
    }
}

关键点： Pact使用matchers（匹配器）来定义灵活的契约规则，而不是固定值。例如matchers.Integer()表示期望整数类型，matchers.StringRegex()表示期望符合正则表达式的字符串。这种设计让契约既能验证结构，又能容忍合理的变化。

4.4.3 提供者端：验证契约

在提供者服务中，加载消费者生成的pact文件，验证实际API是否满足契约要求。

package provider_test

import (
    "testing"
    "net/http"
    "net/http/httptest"
    "github.com/pact-foundation/pact-go/v2/provider"
)

func TestUserAPIProvider(t *testing.T) {
    // 启动真实的提供者服务（或使用httptest.Server模拟）
    handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "application/json")
        w.WriteHeader(http.StatusOK)
        w.Write([]byte(`{"id":12345,"name":"张三","email":"zhangsan@example.com","age":28}`))
    })
    server := httptest.NewServer(handler)
    defer server.Close()

    // 配置提供者验证
    pactVerifier := provider.NewVerifier()

    // 从本地文件加载契约
    err := pactVerifier.VerifyProvider(t, provider.VerifyRequest{
        ProviderBaseURL: server.URL,
        PactFiles:       []string{"../consumer/pacts/user-web-app-user-api-service.json"},
        Provider:        "user-api-service",
    })

    if err != nil {
        t.Fatalf("契约验证失败: %v", err)
    }
}

4.5 契约测试的CI/CD集成

在DevOps流水线中，契约测试通常按以下步骤集成：

消费者构建阶段： 运行消费者测试，生成pact文件，并发布到Pact Broker。
提供者构建阶段： 从Pact Broker拉取最新契约，运行提供者验证测试。
契约门禁： 如果验证失败，阻止提供者部署，并通知消费者团队。
版本管理： Pact Broker支持契约版本管理，确保消费者与提供者的版本兼容。

常见陷阱：

契约测试不能替代集成测试，它只验证接口契约，不验证端到端业务逻辑。
避免在契约中使用过于宽松的匹配器（如matchers.Anything()），否则会降低契约的约束力。
契约文件应纳入版本控制，并与服务版本保持同步。

4.6 本章小结

契约测试通过消费者驱动的契约定义，在微服务间建立了明确的接口约定。与单元测试和集成测试相比，契约测试在测试速度、反馈周期和变更敏感度之间取得了良好平衡。使用pact-go可以快速在Go Web服务中落地CDC测试，配合Pact Broker实现契约的共享与版本管理，为后续的压测闭环提供可靠的接口保障。