契约测试拨乱反正：最简介绍
一段时间以来研究和实践契约测试，发现如过去大家对于单元测试、集成测试、端到端测试等等测试理解不一致一样，绝大多数情况下都把契约测试理解或应用错了。
为了统一认知，写了个简介，以求被拍砖和拍人。
目的（解决的问题）
契约测试是一种以自动化测试作为技术手段，解决团队间因存在明显沟通边界，由沟通不畅和代码变更而造成的系统间接口不匹配问题的最佳实践。
原理
通过测试驱动生成服务间的契约文档，利用该契约文档和Mock Server（银行业常称之为“挡板”）分别对契约的消费者和提供者进行自动化测试，以确保双方能够按照契约实现满足规格要求的接口，并利用持续集成流水线实现对双方变更影响的快速反馈。
原则
- 快速反馈
- 契约测试应当聚焦对于接口规则的验证，能够易于编写，快速运行，最简验证。所以通常采用测试替身（Test Double）来代替集成组件加快运行速度（速度与单元测试相当）。
- 测试运行时使消费者与提供者解耦（分别运行测试）
- 对于接口的功能验证，应当由接口集成测试来保证。
- 对于系统间的协作验证，应当由系统间集成测试，或端到端测试来保证。
- 消费者驱动设计优于提供者驱动设计
- 符合需求拉动和简单设计思想，减少冗余设计。
适用场景 / 条件
- 契约测试属于进阶自动化测试实践，团队需具备基本的自动化测试和持续集成实践能力，并了解微服务基本知识和概念。
- 系统间采用松耦合的通讯和开发方式，例如HTTP+JSON。而非紧耦合的通讯和开发方式，例如共享接口文件的RPC类框架。
- A团队与B团队间存在明显的沟通边界，但二者均可控（可采用统一实践并坚持）。
- 提供者提供的接口被多个消费者消费，需要快速反馈代码变更所造成的影响。
前置知识与能力
- 自动化测试基础
- 单元测试
- 集成测试
- 端到端测试
- 测试替身
- 简单设计（增量式设计）/ 测试驱动开发
- API测试方法
- 版本控制
- 持续集成 / 持续交付
- 微服务
可用工具
- Pact（推荐）
- 消费者驱动
- Pact Specification 契约规范 + 多技术栈实现
- 基于JSON的契约文件
- 支持HTTP+JSON的接口实现 / 消息队列
- Spring Cloud Contract
- 提供者驱动 / 消费者驱动
- JVM + Spring 技术栈，可与Pact Broker集成
- 基于JAR的契约文件
- 支持HTTP+JSON的接口实现 / 消息队列
欢迎关注我的微信公众号
微信搜索：枪炮与代码，或者搜索公众号ID：guns_n_code
