OpenAPI 生成器与使用 Pact 的 CDC 测试
OpenAPI Generator vs. CDC Testing with Pact
我们正在彻底检查我们的前端和后端服务合同的可靠性，并正在调查两个似乎有冲突的 tools/techniques。使用 openapi generator vs. consumer driven contract (CDC) testing with a tool like pact.
等工具从 OpenAPI 规范 (OAS) 生成消费者和提供者代码
OAS 代码生成
OAS 非常适合生成消费者代码，我们正在努力集成提供商端生成以完成双方的合同信任。只要合同更改从 OAS 开始，并且提供者和消费者生成他们的代码，这是合适的策略吗？
Pact 单元测试
Pact CDC 测试似乎根本不涉及 OAS，而是通过单元测试以编程方式在消费者和提供者之间建立契约。使用契约代理时，添加 can-i-deploy 工具似乎是对 ci/cd 管道的一个很好的添加。带有协议的一件好事是它似乎支持 kafka 事件模拟，这将是 openapi-generator 没有涵盖的内容。
如果前端和后端的每个服务都使用 OAS 代码生成，pact 有用吗？我可以在没有 codegen 的环境中看到它的实用性，但在其他方面开始感觉 redundant/conflicting.
感谢您提供的任何见解或轶事！
Pact 是一个合同测试框架，它使用示例规范来确保提供者真正实现消费者的需求。这消除了歧义，但要付出代价（编写/维护测试）。需要注意的是，这里的现状是 end-to-end 测试，比合同测试（为此目的）更昂贵。
这篇 article 讨论了模式之间的差异以及它们与合同测试的关系，以及它们如何一起使用。
If every service, front and back, is using OAS code generation, is pact useful?
这里的简短回答是，如何确保消费者和提供者的 compatible 版本同步？如果您的提供者版本之间存在重大更改，您现在需要同步所有消费者的发布。如果发布有问题，则需要将其全部撤消——这是合同测试解决的关键问题。
Pact CDC testing doesn't seem to involve an OAS at all
Pactflow 有 feature to combine these two approaches, but the philosophy behind it is outlined here
When using a pact broker, the addition of the can-i-deploy tool seems like a nice addition to a ci/cd pipeline. One nice thing w/ pact is that it appears to support kafka event mocking, which would be something openapi-generator doesn't cover.
是的，这更多是 Pact Broker 和 Pact 生态系统的实际好处。如果您需要扩展到 REST（以及 OAS）可以记录的范围之外，您将需要一个不同的策略。对于这些用例，Pact 可能更通用。
我们正在彻底检查我们的前端和后端服务合同的可靠性，并正在调查两个似乎有冲突的 tools/techniques。使用 openapi generator vs. consumer driven contract (CDC) testing with a tool like pact.
等工具从 OpenAPI 规范 (OAS) 生成消费者和提供者代码OAS 代码生成
OAS 非常适合生成消费者代码，我们正在努力集成提供商端生成以完成双方的合同信任。只要合同更改从 OAS 开始，并且提供者和消费者生成他们的代码，这是合适的策略吗？
Pact 单元测试
Pact CDC 测试似乎根本不涉及 OAS，而是通过单元测试以编程方式在消费者和提供者之间建立契约。使用契约代理时，添加 can-i-deploy 工具似乎是对 ci/cd 管道的一个很好的添加。带有协议的一件好事是它似乎支持 kafka 事件模拟，这将是 openapi-generator 没有涵盖的内容。
如果前端和后端的每个服务都使用 OAS 代码生成，pact 有用吗？我可以在没有 codegen 的环境中看到它的实用性，但在其他方面开始感觉 redundant/conflicting.
感谢您提供的任何见解或轶事！
Pact 是一个合同测试框架，它使用示例规范来确保提供者真正实现消费者的需求。这消除了歧义，但要付出代价（编写/维护测试）。需要注意的是，这里的现状是 end-to-end 测试，比合同测试（为此目的）更昂贵。
这篇 article 讨论了模式之间的差异以及它们与合同测试的关系，以及它们如何一起使用。
If every service, front and back, is using OAS code generation, is pact useful?
这里的简短回答是，如何确保消费者和提供者的 compatible 版本同步？如果您的提供者版本之间存在重大更改，您现在需要同步所有消费者的发布。如果发布有问题，则需要将其全部撤消——这是合同测试解决的关键问题。
Pact CDC testing doesn't seem to involve an OAS at all
Pactflow 有 feature to combine these two approaches, but the philosophy behind it is outlined here
When using a pact broker, the addition of the can-i-deploy tool seems like a nice addition to a ci/cd pipeline. One nice thing w/ pact is that it appears to support kafka event mocking, which would be something openapi-generator doesn't cover.
是的，这更多是 Pact Broker 和 Pact 生态系统的实际好处。如果您需要扩展到 REST（以及 OAS）可以记录的范围之外，您将需要一个不同的策略。对于这些用例，Pact 可能更通用。