---

名称: 使用Pact进行契约测试 描述: 使用Pact为微服务实现消费者驱动的契约测试。

使用Pact进行契约测试

概述

契约测试验证服务消费者和提供者之间就请求/响应期望达成一致。Pact通过可共享的契约文件和提供者验证来实现消费者驱动的契约（CDC）。

目录

1. 什么是契约测试
2. 消费者驱动的契约
3. Pact基础
4. Pact与集成测试对比
5. 编写消费者测试
6. 提供者验证
7. Pact Broker
8. CI/CD集成
9. 双向契约
10. 异步消息
11. GraphQL
12. 语言支持
13. 模式与反模式
14. 破坏性变更策略
15. 合规性监控

---

什么是契约测试

契约测试无需完整的端到端设置即可验证API交互。它们通过明确验证期望来防止破坏性变更。

消费者驱动的契约

消费者定义期望；提供者必须满足它们：

• 为消费者提供更快的反馈
• 清晰的API期望
• 减少集成意外

Pact基础

• 消费者测试：生成契约文件。
• 提供者验证：验证契约文件。
• 契约文件：JSON格式的契约。
• Pact Broker：存储和管理契约。

Pact与集成测试对比

• Pact：验证接口兼容性。
• 集成测试：验证完整的系统行为。

两者结合使用以实现全面的覆盖。

编写消费者测试

使用匹配器定义交互：

• 精确值匹配
• 基于类型的匹配器
• 正则表达式匹配器

示例（TypeScript）：

await provider.addInteraction({
  state: '用户存在',
  uponReceiving: '获取用户',
  withRequest: { method: 'GET', path: '/users/123' },
  willRespondWith: {
    status: 200,
    body: { id: like(123), name: like('Alice') }
  }
});

提供者验证

提供者根据已发布的契约进行验证：

• 实现状态处理程序
• 验证响应头/体/状态
• 支持待处理和工作中的契约，以实现安全变更

Pact Broker

关键特性：

• 发布和版本化契约
• 新契约的Webhook
• 部署前的“我能部署吗”检查
• 兼容性可见性

CI/CD集成

推荐流程：

1. 消费者测试生成契约
2. 将契约发布到Broker
3. 提供者在CI中验证
4. 发布前使用“我能部署吗”检查

双向契约

支持提供者定义的期望加上消费者约束：

• 适用于GraphQL或模式优先的API
• 防止提供者漂移

异步消息

Pact支持基于消息的契约：

• 定义消息负载期望
• 验证消费者和提供者处理程序

GraphQL

契约测试模式和查询响应：

• 使用模式作为契约基线
• 验证查询响应结构

语言支持

可用的SDK：

• JavaScript/TypeScript
• Python
• Java
• Go

模式与反模式

良好实践：

• 使用灵活的匹配器
• 保持交互聚焦

避免：

• 过度指定精确值
• 一个契约涵盖多个不相关的案例

破坏性变更策略

• 使用待处理契约进行向后兼容的变更。
• 需要破坏性变更时对API进行版本控制。
• 在消费者迁移前维护旧契约。

合规性监控

在CI中跟踪契约验证，并在验证运行失败时发出警报。

相关技能

• 16-测试/集成测试
• 09-微服务/服务设计
• 03-后端API/express-rest