契约测试实践篇

前提

在前一篇文章《契约测试理论篇》中，详细阐述了契约测试解决的问题，工作原理以及主要的一些实践等。但是如何真正的实现一套契约测试，仍然需要了解和学习更多细节步骤才能完成。现在我们就来看如何实现一套完整的契约测试。

由于契约测试的特殊性，很难手动执行，所以一般情况下它都是通过自动化的方式来实施。业界有多个开源免费的契约测试自动化框架，其中最为常用的就是Pact 和 Spring Cloud Contract，并且契约测试也分为基于消费者驱动的契约测试（Consumer Driven Contract Test，即CDCT）和基于提供者驱动的契约测试（Provider Driven Contract Test，即PDCT）。其中提供者驱动的契约测试本质上和消费者驱动的契约测试的区别只是契约的制定和修改的流程，以及消费者端代码实现会有所区别，其他的基本是一样的。

假设一个基于前后端分离的和微服务的在线支付系统，其中微服务的数量有10多个，每个服务也有10多个Web API，并且所有的后端的服务都通过BFF（Back For Frontend）层来统一给前端应用提供服务，其中每个微服务是一个独立的服务团队进行开发和维护，而BFF层由前端。在这种项目中我们首先需要制定测试策略，在测试策略中就需要确定是不是需要做契约测试，如果确定了需要做契约测试，那么需要通过以下四步来实施契约测试：1，确定契约测试的范围和框架；2，确定契约测试的流程和规则；3，编写契约测试的代码并执行测试；4，管理契约测试。如果能有效的实施这四个步骤，那么契约便能发挥其功效，高效的保证大量微服务之间的交互正确性。

实践步骤

1. 确定契约测试的范围和框架

在这个假设的项目中，首先根据测试测试策略，确定了需要实施契约测试。然后需要确定契约测试的范围。理论上契约需要所有的API消费端和提供端都实施，但是由于本项目中BFF层是前端开发团队自己实施的，所以通过讨论前端团队可以内部在开发的时候保证统一编写和修改前端应用和BFF的相关代码。所以他们以BFF层作为消费端去驱动后端相关的所有微服务。然后又和后端的所有微服务团队讨论，他们同意编写契约测试，但是他们有些服务调用了第三方的其他服务，而这些服务是不属于项目开发，维护等可控制范围，所以无法实施契约。因此项目的契约测试实施范围为BFF与微服务之间，以及微服务与微服务之间。如果项目中前端应用和BFF分别是由两个不同的团队负责开发，那么它们两个也应该实施契约测试。

契约测试实施图：

​ 

其次Pact和消费者驱动的契约测试是最为常用的，并且本项目BFF层是基于NodeJS，而后端的微服务是基于Spring，所以经过讨论最终选择了Pact作为契约测试自动化框架，因为需要同时支持JavaScript和Java两门语言，并且可以通过Pact Broker提供微服务的调用关系图。而Spring Cloud Contract作为后起之秀，还有一些地方需要改进，比如只支持Java，没有Pack Broker这样的集中化，图形化的契约中心化管理系统。

2. 确定契约测试的流程和规则

在确定了契约测试范围