契约测试拨乱反正：最简介绍

版权声明：本作品采用【知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议】进行许可。

---

一段时间以来研究和实践契约测试，发现如过去大家对于单元测试、集成测试、端到端测试等等测试理解不一致一样，绝大多数情况下都把契约测试理解或应用错了。

为了统一认知，写了个简介，以求被拍砖和拍人。

目的（解决的问题）

契约测试是一种以自动化测试作为技术手段，解决团队间因存在明显沟通边界，由沟通不畅和代码变更而造成的系统间接口不匹配问题的最佳实践。

原理

https://martinfowler.com/articles/practical-test-pyramid.html

通过测试驱动生成服务间的契约文档，利用该契约文档和Mock Server（银行业常称之为“挡板”）分别对契约的消费者和提供者进行自动化测试，以确保双方能够按照契约实现满足规格要求的接口，并利用持续集成流水线实现对双方变更影响的快速反馈。

原则

• 快速反馈
  • 契约测试应当聚焦对于接口规则的验证，能够易于编写，快速运行，最简验证。所以通常采用测试替身（Test Double）来代替集成组件加快运行速度（速度与单元测试相当）。
• 测试运行时使消费者与提供者解耦（分别运行测试）
  • 对于接口的功能验证，应当由接口集成测试来保证。
  • 对于系统间的协作验证，应当由系统间集成测试，或端到端测试来保证。
• 消费者驱动设计优于提供者驱动设计
  • 符合需求拉动和简单设计思想，减少冗余设计。

适用场景 / 条件

1. 契约测试属于进阶自动化测试实践，团队需具备基本的自动化测试和持续集成实践能力，并了解微服务基本知识和概念。
2. 系统间采用松耦合的通讯和开发方式，例如HTTP+JSON。而非紧耦合的通讯和开发方式，例如共享接口文件的RPC类框架。
3. A团队与B团队间存在明显的沟通边界，但二者均可控（可采用统一实践并坚持）。
4. 提供者提供的接口被多个消费者消费，需要快速反馈代码变更所造成的影响。

前置知识与能力

• 自动化测试基础
  • 单元测试
  • 集成测试
  • 端到端测试
• 测试替身
• 简单设计（增量式设计）/ 测试驱动开发
• API测试方法
• 版本控制
• 持续集成 / 持续交付
• 微服务

可用工具

• Pact（推荐）
  • 消费者驱动
  • Pact Specification 契约规范 + 多技术栈实现
  • 基于JSON的契约文件
  • 支持HTTP+JSON的接口实现 / 消息队列
• Spring Cloud Contract
  • 提供者驱动 / 消费者驱动
  • JVM + Spring 技术栈，可与Pact Broker集成
  • 基于JAR的契约文件
  • 支持HTTP+JSON的接口实现 / 消息队列

广告时间

如果你对我所就职的ThoughtWorks感兴趣，希望加入的话，欢迎使用我的专属内推通道（转正成功送你高端机械键盘）：

点此进入专属内推通道