共计 1563 个字符，预计需要花费 4 分钟才能阅读完成。
什么是契约测试？
契约测试是一种用于独立测验每个应用程序之间集成问题的测试技术，验证零碎发送或接管的格式化数据，是否匹配“契约”文档。对于通过 HTTP 协定进行通信的程序，这些“音讯”将是 HTTP 的申请和响应，而对于应用队列的程序，则是队列中传递的音讯。实际上，契约测试最简略的一种实际形式是，通过查看上下游的所有调用与返回是否与理论后果雷同。
契约测试非常适合于任意两个须要通信的服务：比方一个 API 服务器和一个 web 前端，一个服务和它的上游服务。契约测试不单单实用于单服务器 - 客户端模式，也同样实用于现在的微服务体系。契约测试是微服务开发和部署不可或缺的测试内容。
为什么须要契约测试？
试想如下场景，一个 Web 应用程序，其中团队 A 负责开发产品前端，B 团队负责产品服务端开发。我的项目是麻利开发模式，在我的项目开始时，两方团队会在会议上定义所有需要，以及前后端合作、数据传递的形式。之后每个团队相熟需要后，开始创立用户故事，接下来开发团队基于工作紧锣密鼓的进行产品性能研发。等前后端开发实现后，会在前面的迭代中安顿进行联调、集成测试，验证产品前后端性能匹配。但随着 A 团队的开发进行，发现必须对 API 行为进行革新，团队成员会对 API 文档进行相应的更新，同时告诉团队 B 进行调整。测试团队则会基于最新的 API 文档进行测试用例的设计，进行产品性能验证。
在这个流程中曾经暴露出了很多问题：
- API 文档的更新很有可能没有告诉到不同团队的开发人员
- 测试团队基于 API 文档进行测试，文档很有可能不是最新的
- 在整个开发周期中，要等到集成环境部署胜利，才可能进行产品性能验证
- 在多版本 API 中更难保障需要、性能验证正确
一旦发现下面的问题，都须要破费大量的工夫在问题定位、批改、部署、验证上，所以咱们须要一种可能较晚期、较疾速暴露出产品间行为不匹配的伎俩，一种能从客户端（终端、最终消费者）验证产品性能是否匹配预期的伎俩。
消费者驱动的契约测试
消费者驱动的契约测试有消费者和提供者两个方面。
消费者
利用另一个应用程序的响应或数据来实现其工作的应用程序。
对于应用 HTTP 的应用程序，消费者始终是发动 HTTP 申请的应用程序。
对于应用队列的应用程序，消费者是从队列中读取音讯的应用程序。
提供者（生产者）
一种应用程序（通常称为接口服务），通常通过 API 为其余应用程序提供性能或数据。
对于应用 HTTP 的应用程序，提供者是返回响应的应用程序。
对于应用队列的应用程序，提供者是将音讯写入队列的应用程序。
消费者和提供者之间的合同称为契约，每个契约都是相互作用的汇合。
对于 HTTP 协定，契约能够蕴含两个方面：
- 预期的申请 – 形容消费者预期发送给提供者的内容
- 冀望响应 – 形容消费者心愿失去的响应内容。
对于音讯队列，应蕴含： - 冀望音讯 – 形容消费者想要应用的音讯内容。
编写契约测试的第一步是定义消费者与提供者的这种相互作用。
消费者测试
流程如下图：
- 应用契约语法，将预期的申请和响应定义到模仿服务中。
- 消费者运行测试代码，向模仿提供者发送实在申请。
- 模仿提供程序将理论申请与预期申请进行比拟，如果比拟胜利，则返回预期响应。
- 消费者测试代码接管返回，确认响应内容正确无误
契约测试只有在每个步骤都没有谬误时，才算胜利。
提供者验证
流程如下图：
在提供者验证流程中，每个申请都被发送到实在的提供者，并将其生成的理论响应与消费者的预期响应进行比拟。
契约测试 Vs 集成测试
契约测试不能取代集成测试。
但它能够取代一些现有的集成测试的场景，使测试左移，在开发阶段尽可能快的暴露出产品行为问题，为软件开发生命周期提供更快的反馈。
在集成测试中，咱们须要验证 API 所在的上下文，例如环境体系结构、部署过程等。
在契约测试中，咱们须要测试 API 的细节，其中包含与 API 构造、内容和谬误响应和一些边缘状况。
下篇分享下微服务框架下的契约测试。
