• 功能测试是关于确保提供者通过请求做正确的事情。这些测试属于提供程序代码库，而编写它们并不是消费者团队的工作。
• 合同测试旨在确保您的消费者团队和提供者团队对每种可能方案中的请求和响应有共同的理解。
• 契约测试应该关注

               暴露消费者如何创建请求或处理响应的错误

               暴露了对提供者如何回应的误解

• 契约测试不应该关注

                 暴露提供程序中的错误（尽管这可能是副产品）

您可以在此处阅读有关合同和功能测试之间差异的更多信息。

计算出测试或不测试内容的经验法则是 - 如果我不包括这种情况，那么消费者中的哪些错误或者对提供者如何响应的误解可能会被遗漏。如果答案是否定的，请不要包括它。

使用Pact进行隔离（单元）测试

• 作为模拟（在测试后验证对模拟的调用）不是存根（对存根的调用未经验证）。使用Pact作为存根会破坏使用Pacts的目的。
• 对于负责从Consumer应用程序到Provider应用程序进行HTTP调用的类的隔离测试（即单元测试），而不是整个消费者代码库的集成测试。
• 仔细地，在您的消费者代码库中进行任何类型的功能或集成测试。

为什么？

如果您使用完全匹配的Pact进行集成测试，那么您将会疯狂。由于Pact会检查每个传出路径，JSON节点，查询参数和标头，因此您将进行非常脆弱的Consumer测试。您最终还会遇到需要在提供商方面进行验证的笛卡尔互动。这将增加您花费在提交者测试通过上的时间，而不会有用地增加测试覆盖率。

仔细考虑如何将它用于非隔离测试（功能，集成测试）

保持孤立，完全匹配测试。这些将确保您将域对象中的正确数据映射到请求中。

对于集成测试，为请求使用松散的，基于类型的匹配以避免脆弱，并将设置拉出到可以在测试之间共享的方法，这样您就不会有一百万次交互来验证（这将有所帮助，因为“契约”中的交互集合就像一个集合，并丢弃完全重复的内容。

如果您不关心验证您的交互，可以使用Webmock之类的东西进行集成测试，并使用共享fixture来处理这些测试和Pact测试之间的请求/响应，以确保您进行某种程度的验证。

通过URL向提供商提供最新协议

请参阅在Consumer和Provider之间共享pacts以获取实现此目的的选项。

确保对提供程序的所有调用都通过已使用Pact测试的类

不要直接在您的Consumer应用程序中手动创建任何HTTP请求。通过客户端类（一个独立负责处理与提供者的HTTP交互的类）进行测试，可以更加确保您的消费者应用程序将创建您认为应该的HTTP请求。

确保您在其他测试中使用的模型实际上可以从您期望的响应中创建

当然，您已经检查过您的客户端将HTTP响应反序列化到您期望的Alligator中，但是您需要确保在另一个测试中创建Alligator时，使用有效属性创建它（例如，Alligator的last_login_time a时间还是日期时间？）。一种方法是使用工厂或夹具为所有测试创建模型。有关更详细的说明，请参阅此要点。

小心垃圾输入，垃圾输出PUT / POST / PATCH

每个交互都是隔离测试的，这意味着您不能执行PUT / POST / PATCH，然后使用GET跟踪它以确保您发送的值实际上由提供者成功读取。例如，如果您有一个可选的姓氏字段，并且您发送了lastname，那么提供者很可能会忽略错误名称字段，并返回200，无法提醒您，您的姓氏已经转到了大/ dev /在天空中无效。

为了确保您没有Garbage In Garbage Out情况，期望响应主体包含新更新的资源值，并且一切都会很好。

如果出于性能原因，您不希望在响应中包含更新的资源，另一种避免GIGO的方法是在GET响应主体和PUT / POST请求主体之间使用共享夹具。这样，您就知道您正在PUTing或POSTing的字段与您将要获取的字段相同。

使用can-i-deploy

使用Pact Broker CLI的can-i-deploy功能。如果您正在部署的消费者版本与其所有提供商兼容，它将为您提供明确的答案。