契约测试Pact(三)

 微服务测试验证成本高

 微服务测试测试结果不稳定

 微服务测试反馈时间长

什么是契约测试#

 契约#

               请求、响应、元数据

契约测试#

               概念：

                       基于契约对生产者和消费者之间的协作进行验证。

 

目的：验证生产者所提供的内容是否能满足我们消费者。作为消费者这一方所期望的东西，如果不能满足，那就意味着契约的破坏。

 

我们要的是鱼香肉丝，结果你给我一个西红柿炒鸡蛋，这就不符合消费者事先的需求，那消费者可能就没办法来正常进行它自己的业务逻辑。

 

契约的概念#

 请求

请求头、请求URL、请求的动作、请求参数

 响应

生产者服务对于前面请求的应答，包含响应的状态码、响应的内容以及错误描述等信息

 元数据

指对消费者和生产者之间的协作过程的描述。比如生产者/消费者的名称、上下文以及场景描述等

 

契约测试（Contract Test）#

 基于契约对消费者与生产者间的协作的验证。本质上就是验证生产者说提供的内容是否满足消费者的期望。

 

分类

两种类型：

 消费者驱动的契约测试

 生产者驱动的契约测试

最常见的的就是 消费者驱动的契约测试（Consumer Driven Contract Test）简称CDC。

 

 

 

 

 

 

契约被破坏的情况：

 

 

 

 

 

 

CDC的核心流程#

 对消费者的业务逻辑进行验证时，先对其期望的响应设计一个模拟生产者(Mock)，并将消费者请求与模拟生产者的响应协作的过程记录为契约文件。

 然后将契约文件对生产者进行回放，从而验证生产者提供的响应内容是否满足消费者的期望。

 

 

 

 

 

只关注请求和响应

 

在开发设计一个新的服务时候，这个CDC非常有用，开发人员可以通过一系列的契约测试用例来确定他们提供的响应内容是否能满足消费者。从而决定API的设计方法。

 

CDC的核心原则#

 CDC是从消费者角度来确定提出契约，然后交给生产者实现，最后以测试用例对契约进行约束。生产者在满足测试用例的情况下，可以执行修改实现接口，而不影响消费者。

 CDC是从利益相关者的角度触发，最大限度的满足需求者的业务价值实现。

 CDC不同于组件测试，不需要深入测试消费者服务的功能，它更侧重于检查服务之间的输入输出是否包含了必要的数据结构和属性

 

 

契约测试的价值#

 契约测试在形式上，虽然测试的是生产者服务，但是在价值上，保证的是消费者服务的业务。

例子

 

生产者对于消费者1，只用到了“id”、"name"，就是说他在消费id、name

生产者对于消费者2，只用到了“id”、"age"，就是说他在消费id、age

生产者对于消费者1，只用到了“id”、"name"、"age"，就是说他在消费id、name、age

这种形式，没有一个确切的消费者，只能叫做公约；三个消费者可以和平共处，相安无事。

 

随着业务越来越复杂，消费者1、2、3有了各自的需求，于是产生了如下图情况：

 

 

通过上面例子可以发现：

 消费者1业务产生变化，需要给用户提供 [姓、名]，对于生产者来说，实现起来不难

 消费者2保持不变，生产者依然能满足其需求

 消费者3保持不变，这时候生产者无法满足其需求了，因为“name”字段由消费者1的变化而产生了改变，导致消费者3无法接受和使用，这时候产生了契约破坏

 

这有利于开发者在修改或新增接口的时候预先判断-是否能满足所有的消费者需求

如果公约的某一部分不对任一消费者使用的时候，这时候开发可以任意修改。

对于一个生产者一个消费者的这种情况，使用集成测试足以满足，不需要契约测试，只有【生产者对多个消费者的情况下才适用契约测试】