契约测试

1. 契约测试适用场景
2. 微服务下遇到的问题
3. 契约分类
4. 契约的步骤
5. 契约框架
6. 契约管理
7. wiremock的介绍
8. spring cloud contract介绍
9. pact介绍

 

契约测试的适用场景

微服务或者分布式系统，且服务的通信采用restful api，前后端同时开发。

rpc的分布式的系统，如，前后端不是同时开发

 

微服务遇到的难处

1. 前后端分离，业务分离，团队分离，各个服务由独立的团队开发，调用链路复杂
2. 服务提供方与服务消费方都存在联调，如果消费方与提供方同时开发的话，消费方就必须做mock ,做Java 里面有个wiremock 是做serverMock的工具。
3. 微服务的提供方很有可能会被多个服务调用，
4. 问题：1.可能会发现mock的数据跟provider提供的数据相差很大，2.provider 可能会为了某个服务提的需求更改数据结构或者增加属性，在某一时刻修改提供的接口，跑碰巧多个consumer 同时在调用这个服务接口，这样导致很多问题，如果发现的晚的话，或者都在端到端测试去发现，导致花时间过长，问题排除困难。3.随着业务的深入会不断的去修改接口，不能快速反应问题

 

服务测试—面向契约测试（pact 、spring cloud contract）

服务契约（提供者契约与消费契约）

提供者契约（ Provider contracts ） —— 提供者契约是我们最为熟悉的一种的服务契约，参考 WSDL+XML Schema+WS-Policy 。顾名思义，提供者契约是以提供者为中心的。提供者规定了它要提供什么；然后，各消费者便将自己绑定到这个一成不变的契约上。不论消费者实际需要多少功能，消费者接受了提供者契约，就将自己与该提供者的全体功能耦合起来了。 
消费者契约（ Consumer contracts ） —— 另一方面，消费者契约是对一个消费者的需求更为精确的描述。消费者契约描述了，在一次具体交互场合下，提供者功能中消费者需要的特定部分。消费者契约可被用来标注一个现有的提供者契约，另外消费者契约也有助于发现一个现今尚未规定的提供者契约。 
消费者驱动的契约（ Consumer-driven contracts ） —— 消费者驱动的契约描述的是服务提供者向其所有当前消费者承诺遵守的约束。一旦各消费者把自己的具体期望告知提供者，消费者驱动的契约就被创建了。在提供者方面创建的约束，确定了一个消费者驱动的契约。若提供者接受了一个消费者驱动的契约，那么它只需保证已有约束仍能得到满足，即可自行改进与修改其服务 。

提供了消费者驱动契约可以编写用例来同时保证提供方与消费方准守契约，同时服务提供方自动化单元测试时也准守消费者驱动契约

 

 

 

 

 

 

契约测试的框架

 

PACT

轻量级、支持多种语言应用、支持与 Maven/ Gradle 等集成

Spring Cloud Contract

支持基于 JVM 的应用、支持与 Spring 其它组件集成