试着说服我：为什么我要使用Pact？

假如我认为端到端(E2E)的集成测试也挺好的?

请阅读以下文章：

研究告诉我们，集成测试在时间、团队精力和维护方面的成本更加昂贵，却并没有给予我们更多质量保障。

Pact相当于VCR相反的功能。VCR记录服务提供者的行为，然后来验证服务消费者的行为是否符合预期。而Pact记录了服务消费者的行为，来验证服务提供者是否满足预期行为。Pact的优点有：

OpenAPIs和Pact的设计目的不同，之间的区别可以归纳如下：

Swagger/OpenAPI规范旨在标准化API的描述及结构。它能够告诉你哪些API是可以使用的，这些API期望的字段和结构，并可以生成相应的文档/UI来与之交互。但它并不是一个测试框架。

与之不同的是，Pact本质上是一个通过示例来描述 的单元测试框架。只是为了能够在API的消费者和提供者端运行这些测试，它需要生成一种能够表达API结构的中间格式——这就是Pact规范。

事实上，OpenAPI规范的作者预测了这样的使用场景：

像测试工具这样的附加程序也能够利用结果文件。例如，我们可能会使用一些扩展程序来记录在规范中提到的元数据。这是两个项目可以协同工作的一种方式。

假如你正在使用Swagger，请参阅这篇文章Swagger模拟验证器，它是Atlassian开发的一个插件，旨在统一这种项目协同工作的方式。

与Pact一起使用的话，对于API是否满足任何已发布的规范（对于外部客户端来说），能够给予你更多信心，同时对于任何已知的（内部）消费者端需求是否能够满足，也可以给予你更多信心。

端到端（E2E）测试有几个关键问题：

你可以以此作为试金石: 如果你能够直视别人的眼睛并告诉他们你并没有花太多时间来维护E2E环境或者对测试管理并没有持续的挑战，那么你可以选择其他方式。但是当团队中有一个或多个人致力于管理发布流程，那么这种迹象可能表明你正处于错误的方向。

假如你真想使用E2E测试，可以考虑将你的E2E测试的部分场景推到流水线后半段，作为一种“冒烟测试”，只是在向用户发布之前运行几个关键场景。

注意: 你需要综合考虑，切忌不可不分良莠，好坏一起丢。

请参考问题”但是我已经有了以小时运行的端到端（E2E）集成测试怎么办”。所有的问题依然存在，只是Docker掩盖了这些痛点（或将问题推迟暴露）。

那么你可能正在给多个消费者开发API，我说的对吗？假如你不确定你的服务消费者是谁，那么Pact可能不适合你。假如你能够掌控任意一个消费者，那么Pact可能会适合你——只不过你的需求并不是从消费者驱动而来（这也没有关系）。

很好，你确实不该一开始就信任我们。你应该在盲目推崇Pact之前首先在一个较小的项目上评估以证明其价值。

事实上，你甚至并不是必须得使用Pact才能完成契约测试并取得收益——Pact只是使契约测试更容易些。

你只是说说而已，来让我们好受一些吗？

以下是些建议，帮助你赢得朋友们的支持：