Pact中文参考指南

Pact是什么

Pact是一个用于实现消费者驱动的契约测试的框架。关于什么是消费者驱动的契约测试，可以参见这篇文章，不再赘述。这里只说明契约测试对于构建复杂软件系统的重要作用。

系统工程里有这样一个规律，线性系统（即复杂性随规模线性增长的系统）的可靠性等于组成它的各个组件的可靠性之乘积。这容易理解，因为整个系统正常工作的条件是必须每个组件都同时正常工作。

线性系统的可靠性

也就是说，如果一个系统由三个可靠性各为90%的组件组成，那么整个系统的可靠性实际只有90%×90%×90%=72.9%，低于任一组件的可靠性。如果一个系统由100个组件组成，每个组件即使能达到99%的可靠性，那么整个系统的可靠性也会降到36.6%左右。

然而，一个复杂软件系统的情形可能更糟，因为软件系统实际上是非线性系统。组成软件系统的各个组件之间有依赖与连接关系，除了要让每个组件正常工作之外，还需要保证各个组件之间的调用正常。如果将每个组件视为一个微服务的话，每个微服务上暴露出的接口不止一个，组件两两之间的连接关系又不止一条。如此算来，在微服务规模不断增长的情况下，系统的复杂度已不止线性增长，因此整个系统的可靠性将会比各组件可靠性的乘积还要更低。

因此，在构建由微服务组成的复杂软件系统时，除了保证每个微服务组件的正确性之外，还必须通过测试验证微服务之间连接的正确性。

Pact框架解决的就是如何测试微服务之间连接正确性的问题。

传统方式下，一般通过集成测试来验证服务之间调用是否正常，这需要将被测的各个组件均部署到环境中，然后再展开测试，且不说这种方式下测试运行得如何之慢，只是把各个服务都部署到同一环境之中这件工作，对于许多经常搭环境的开发者来说，就已经非常繁琐而痛苦了。而且由于多个服务共享同一环境，测试也比较脆弱，很容易挂。

Pact是一个思路精巧、设计优雅的测试框架。它通过将一个笨重的集成测试化为两个可以独立运行的单元测试和接口测试来解决这一问题。两步即可完成：

Step 1：服务消费者端编写单元测试，测试对服务提供者接口的客户端请求类。一运行测试，Pact框架便帮助自动生成json形式的pact文件（契约文件）。pact文件中含有交互的路径、方法、请求参数、请求头与期望响应等信息。
Step 2：单独启动服务提供者（此时并不需要启动服务消费者），利用Pact框架提供的验证命令进行契约验证，基于上一步中生成的pact文件，对服务提供者的接口发送请求并验证实际响应是否与期望响应相符。

这种方式至少有明显的几个好处：

服务测试解耦。两个测试之间唯一的耦合点是pact文件（自动生成），自然实现了服务消费者端与提供者端的测试解耦，再也不需要等待“联调”就能各自展开开发。
消费者驱动。由于契约文件是由服务消费者的单元测试驱动而成的，服务提供者只要能够正确通过契约验证，就能保证满足服务消费者端的需求。这一思想其实与敏捷实践中的测试驱动开发（TDD）有异曲同工之处。
测试前移。越早发现问题，解决问题的成本就越小。由于Pact测试已经足够轻量化，开发者甚至在本地开发阶段就可以进行相关的测试，而不需要等到集成阶段才暴露问题。

Pact的前世今生

Pact是一个开源框架，最早是由澳洲最大的房地产信息提供商REA Group的开发者及咨询师们共同创造。REA Group的开发团队很早便在项目中使用了微服务架构，并在团队中对于敏捷和测试的重要性早已形成共识，因此设计出这样的优秀框架并应用于日常工作中也是十分自然。

Pact工具于2013年开始开源，发展到今天已然形成了一个小的生态圈，包括各种语言（Ruby/Java/.NET/JavaScript/Go/Scala/Groovy...）下的Pact实现，契约文件共享工具Pact Broker等。Pact的用户已经遍及包括RedHat、IBM、Accenture等在内的若干知名公司，Pact已经是事实上的契约测试方面的业界标准。