契约测试之Pact

1. 前言

有近两周没有在公众号中发表文章了，看过我之前公众号的读者都知道，公众号中近期在连载《RobotFramework接口自动化系列课程》，原本计划每周更新一篇，最近由于博主在带一个新项目，实在是没空抽出时间来，所以向公众号中对连载课程一直期待的读者说声抱歉。

由于最近带微服务的项目，而对于微服务其实也是近从14年才流行起来，对于这块目前的干货内容还是较少，借着机会，小结一下知识点。所以今天也先不打算连载《RobotFramework接口自动化系列课程》，如果读者对连载的课程比较热衷的话，可以在留言板下面给笔者留言，如果读者反馈较多的话，博主也会适当加快调整课程分享节奏。

下面给大家浅聊一下微服务架构下的契约测试。

2. 微服务特点

Microservice微服务是一种架构风格，我们可以把每一个微服务视做一个用一组API提供业务功能的组件，且服务之间会有很多依赖关系，如下图所示：

这些服务之间可能由一个团队或者相互独立的团队开发和维护，并且它们在系统内部相互依赖，在这种情况下，接口的开发和维护可能会带来一些问题，例如服务端调整架构或接口调整而对消费者不透明，导致接口调用失败。

3. 微服务下的测试现状

例如， 我们想测试某微服务架构中的某一个服务时，比如下图第一排中间的服务，如：

因为它和其他服务都存在交互，一般我们有两种方式：

• 部署所有的服务来实现端到端测试。
• 在集成测试中Mock其他服务。

下面分析一下这两种方式优缺点：

4. 微服务下的开发现状

常规我们开发的项目主要由服务提供方约定接口，虽然提供方架构调整或改变接口之前通常会通知消费者，但可能还是会存在遗漏。

当一个Service已经同时被多个使用者调用用的时候，怎么保证service的修改对其它所有使用者造成影响被感知到呢？

5. 什么是契约测试

契约测试 ，又称之为 消费者驱动的契约测试(Consumer-Driven Contracts，简称CDC)，根据 消费者驱动契约 ，我们可以将服务分为消费者端和生产者端，而消费者驱动的契约测试的核心思想在于是从消费者业务实现的角度出发，由消费者自己会定义需要的数据格式以及交互细节，并驱动生成一份契约文件。然后生产者根据契约文件来实现自己的逻辑，并在持续集成环境中持续验证。

后文中消费者驱动的契约测试统一用cdc来代替。

5.1 cdc核心原则

• cdc是以消费者提出接口契约，交由服务提供方实现，并以测试用例对契约进行产生约束，所以服务提供方在满足测试用例的情况下可以自行更改接口或架构实现而不影响消费者。
• cdc是一种针对外部服务的接口进行的测试，它能够验证服务是否满足消费方期待的契约。 它的本质是从利益相关者的目标和动机出发，最大限度地满足需求方的业务价值实现。

5.2 常见测试框架

业界常用的CDC测试框架有：

• Janus
• Pact
• Pacto
• Spring Cloud Contract

6、契约测试、单元测试、接口测试之间的区别

• API测试和单元测试，更强调的是覆盖API内部逻辑。
• 契约测试，更强调是组件之间连接的正确性，除了保证组件内部，还要保证组件间的调用是正确的，也就是服务API之间的调用。

7. 契约测试能解决什么问题

• 联调成本过高,要双方开发到某一