1.6.1 为什么使用Pact？
- 更快的执行速度。
- 来自于模拟服务的可靠响应能够降低测试的不稳定性。
- 更易定位测试失败的原因，因为一次只测试单个组件。
- 帮助改进服务提供者的设计，因为优先考虑数据实际是怎样被使用的，而不是优先考虑数据是否最容易被获取或序列化。
- 不需要为自动化集成测试专门维护一套或多套环境——契约测试可在独立的CI流水线中运行。
- 传统意义上需要同时运行多个服务的集成流程可被分解为多个集成点，每个集成点可被单独测试。
假如我认为端到端(E2E)的集成测试也挺好的?
请阅读以下文章：
- http://googletesting.blogspot.com.au/2015/04/just-say-no-to-more-end-to-end-tests.html
- http://blog.thecodewhisperer.com/permalink/integrated-tests-are-a-scam
- 假如你依然更倾向于端到端的集成测试，请阅读软件过程质量中的缺陷分析及预防
研究告诉我们，集成测试在时间、团队精力和维护方面的成本更加昂贵，却并没有给予我们更多质量保障。
不使用Pact的常见理由
......我在本地已经有个模拟服务了(例如： VCR，MockServer)
Pact相当于VCR相反的功能。VCR记录服务提供者的行为，然后来验证服务消费者的行为是否符合预期。而Pact记录了服务消费者的行为，来验证服务提供者是否满足预期行为。Pact的优点有：
- 使你能够在开发服务提供者（例如：提供JSON的后台API）之前就开发服务消费者（例如：一个基于Javascript的富客户端）。
- 能够首先驱动出服务提供者端的需求，这意味着在提供者端能够更准确地实现最小化需求。
- 以良好的文档展现的用例（“给定......的请求，将返回......”），准确描述了如何使用服务提供者。
- 能够看到每个服务消费者分别关注哪些字段，允许在服务提供者端API中删除未经使用的字段，增加新的字段，而不影响服务消费者使用。
- 当服务提供者API发生了变更时，能够立即看到哪个消费者的功能被破坏了。
- 通过使用 Pact Broker，能够直观地展示服务间的关系。
请参阅https://github.com/realestate-com-au/pact/wiki/FAQ 来查看更多类似技术的示例。
...我已经使用了Swagger/OpenAPI?
OpenAPIs和Pact的设计目的不同，之间的区别可以归纳如下：
Swagger/OpenAPI规范旨在标准化API的描述及结构。它能够告诉你哪些API是可以使用的，这些API期望的字段和结构，并可以生成相应的文档/UI来与之交互。但它并不是一个测试框架。
与之不同的是，Pact本质上是一个通过示例来描述 的单元测试框架。只是为了能够在API的消费者和提供者端运行这些测试，它需要生成一种能够表达API结构的中间格式——这就是Pact规范。
事实上，OpenAPI规范的作者预测了这样的使用场景：
像测试工具这样的附加程序也能够利用结果文件。例如，我们可能会使用一些扩展程序来记录在规范中提到的元数据。这是两个项目可以协同工作的一种方式。
假如你正在使用Swagger，请参阅这篇文章Swagger模拟验证器，它是Atlassian开发的一个插件，旨在统一这种项目协同工作的方式。
与Pact一起使用的话，对于API是否满足任何已发布的规范（对于外部客户端来说），能够给予你更多信心，同时对于任何已知的（内部）消费者端需求是否能够满足，也可以给予你更多信心。
更多资料参见https://github.com/pact-foundation/pact-specification/issues/28。
......但是我已经有了以小时运行的端到端（E2E）集成测试怎么办？
端到端（E2E）测试有几个关键问题：
- E2E测试非常耗时——缓慢的构建时间会导致批量更改。批量更改不利于持续交付。
- E2E测试很难协调。您如何确保 所有的 软件组件都准确地处于正确的版本？
- E2E测试的复杂性是非线性的——随着时间的推移会变得越来越困难和混乱。
- 你为什么要关心其他系统的行为呢？
你可以以此作为试金石: 如果你能够直视别人的眼睛并告诉他们你并没有花太多时间来维护E2E环境或者对测试管理并没有持续的挑战，那么你可以选择其他方式。但是当团队中有一个或多个人致力于管理发布流程，那么这种迹象可能表明你正处于错误的方向。
假如你真想使用E2E测试，可以考虑将你的E2E测试的部分场景推到流水线后半段，作为一种“冒烟测试”，只是在向用户发布之前运行几个关键场景。
注意: 你需要综合考虑，切忌不可不分良莠，好坏一起丢。
......但是我已经使用了Docker？
请参考问题"但是我已经有了以小时运行的端到端（E2E）集成测试怎么办"。所有的问题依然存在，只是Docker掩盖了这些痛点（或将问题推迟暴露）。
......但是我们公司开发API早于开发服务消费者（例如API/文档驱动设计）
那么你可能正在给 多个 消费者开发API，我说的对吗？假如你不确定你的服务消费者是谁，那么Pact可能不适合你。假如你能够掌控任意一个消费者，那么Pact可能会适合你——只不过你的需求并不是从消费者驱动而来（这也没有关系）。
......然而我不信任你和你这些取巧的代码
很好，你确实不该一开始就信任我们。你应该在盲目推崇Pact之前首先在一个较小的项目上评估以证明其价值。
事实上，你甚至并不是必须得使用Pact才能完成契约测试并取得收益——Pact只是使契约测试更容易些。
好吧，我被说服使用Pact了，但我无法说服我的朋友们也使用它。
你只是说说而已，来让我们好受一些吗？
以下是些建议，帮助你赢得朋友们的支持：