Pact设计理念：消费者驱动与模拟测试
pact作为消费者驱动契约（consumer-driven contract, cdc）测试框架，其根本目标是让消费者明确定义其对提供者api的期望。这意味着消费者在自己的测试环境中，通过与一个模拟的提供者服务（pact mock server）进行交互来生成契约。这个契约随后会被提供者用来验证其api是否满足所有消费者的需求。
核心原则：
- 契约由消费者定义： 消费者通过编写测试来声明它期望提供者API如何响应，而不是简单地记录提供者当前的行为。
- 使用模拟服务： 消费者测试应针对Pact提供的Mock Server运行，该Mock Server根据消费者定义的期望来响应请求。
为什么不应直接调用生产服务生成契约？
尝试让Pact消费者测试直接调用真实的生产服务（如开发环境或测试环境）来生成契约，与Pact的设计理念相悖，并且会丧失契约测试的关键优势。
-
失去对API实际使用范围的可见性：
- 如果仅采用“记录/回放”的方式（即直接调用真实服务并记录其响应），Pact将无法得知消费者在提供者响应中实际使用了哪些字段。
- 这意味着提供者必须假设其API某个端点的所有字段对消费者都是重要的。
- 当提供者希望修改或删除某个字段时，它将不得不假设所有消费者都依赖该字段，从而可能被迫进行API版本升级，即使该字段实际上并无消费者使用。
- 相反，如果提供者知道其消费者仅需要字段的一个子集，那么在不影响现有消费者的情况下，可以安全地修改或删除那些未被使用的字段，无需版本化API或与外部团队沟通。
-
引入不确定性与测试复杂性：
- Pact旨在作为一种单元测试工具，提供高度确定性和可重复性的测试结果。
- 直接调用真实的生产服务会引入大量不确定性因素，例如：
- 网络延迟或故障。
- 真实服务的数据状态波动。
- 依赖外部系统或第三方服务。
- 这些因素使得测试结果变得不可靠，难以精确地定位问题，并增加了测试的调试难度。Pact通过模拟服务，确保了消费者测试在隔离且可控的环境中运行。
-
违背消费者驱动原则：
- Pact的精髓在于“消费者驱动”。消费者定义其需求，提供者据此进行验证。
- 如果消费者直接调用真实服务，那么契约实际上是由提供者当前的实现决定的，而非消费者明确的需求。这使得契约测试退化为简单的集成测试或烟雾测试，失去了其在服务解耦和独立部署方面的核心价值。
错误解析与Pact的正确用法
用户遇到的错误信息 au.com.dius.pact.consumer.PactMismatchesException: The following requests were not received: 明确指出Pact Mock Server没有收到预期的请求。这通常发生在消费者测试代码被配置为向真实服务发送请求，而不是向Pact Mock Server发送请求时。Pact Mock Server在启动后会监听一个特定的端口，消费者测试应该将请求指向这个端口。
Pact的正确工作流程：
-
消费者测试：
- 在消费者项目的测试中，启动Pact Mock Server。
- 消费者代码（通常是HTTP客户端）被配置为向Pact Mock Server发送请求。
- 消费者测试定义预期的请求和响应（given、upon receiving、will respond with）。
- 测试执行时，消费者代码向Mock Server发送请求，Mock Server根据预设的期望返回响应。
- 如果请求与期望不符，或Mock Server未收到预期请求，则测试失败。
- 测试成功后，Pact会生成一个契约文件（JSON格式）。
-
提供者验证：
- 提供者项目下载（或通过Pact Broker获取）由消费者生成的契约文件。
- 提供者运行Pact验证测试，针对其真实的API端点，根据契约文件中的定义进行请求和响应的验证。
- 如果提供者的API行为与契约不符，则验证失败。
通过这种方式，Pact确保了消费者和提供者对API的理解保持一致，同时避免了直接集成测试的复杂性和不确定性。
总结
Pact框架的核心价值在于其消费者驱动和基于模拟服务的测试方法。尝试让消费者直接调用生产服务来生成契约，不仅会丧失Pact在API可见性、版本管理和测试确定性方面带来的关键优势，而且与Pact的设计理念完全相悖。为了充分利用Pact的强大功能，务必遵循其既定的工作流程：消费者测试针对Pact Mock Server运行以生成契约，提供者则针对真实API验证这些契约。
