java - 关于契约使用的概念性问题

Question

我所在的团队“率先”为我们整个公司使用 pact。在这段旅程中，我们遇到了许多问题，这些问题主要是由于误解了 CDC-Testing 协议(protocol)的使用。随着时间的推移，其中很多问题都可以得到解决，但仍有一些主要问题我无法找到任何好的解决方案或示例。由于我认为回答这些问题非常重要，因此我认为直接与您联系可能会对我们有所帮助。

1. 问题:在实现提供者测试时，我们应该在应用程序的哪个“层”实现我们的测试？
   背景:当我们第一次开始使用 pact 向我们的应用程序添加 CDC 测试时，我们通过启动一个包含内存数据库的应用程序上下文来进行功能测试，并在该数据库中设置数据。这导致了难以维护的测试，此外，我们实际上是在进行功能测试，而 pact 并不是为此而设计的。在多次考虑我们想要如何实现测试的方法之后，我们最终只测试了我们的边界，其中包括其余接口(interface)和(最多)输入和输出验证。
2. 问题:使用多个提供者状态背后的想法是什么？
   背景:Pact 支持在一次交互中使用多个提供者状态。我们尝试了此功能，但我们的许多开发人员并不认为多个提供者状态有很大优势。因此，我们使用 pact 进行的许多 cdc 测试都对提供者状态进行了冗长而复杂的描述。所以我认为我们不了解有关此功能的基本概念。
3. 问题:参数化提供者状态背后的想法是什么？
   背景: 与之前的背景基本相同。我们尝试了此功能，但我们的许多开发人员决定不使用它。因为拒绝该功能是因为没有完全理解该功能，所以我想知道该功能被认为有何用途。
4. 问题:我们应该如何处理有关版本控制策略的协议(protocol)？
   背景:目前，在官方 pact documentation 中记录了使用语义版本控制处理应用程序之间的契约(Contract)。 .我们使用 SNAPSHOT 版本控制，目前无法更改版本控制策略。此外，我们公司中还有多个其他团队，它们具有不同的版本控制策略。基本上不可能在一般情况下就一种策略达成一致。当我们谈论在整个公司使用 cdc 和 pact 时，这意味着什么？这会导致什么问题？正确标记契约(Contract)(主、功能、开发、生产……)是否可以解决任何与版本控制相关的问题？

Answer 1

1. 您的提供商测试不应受到 Pact 的影响。您应该继续编写单元测试和功能集成测试(我所说的集成是指确保服务中的不同组件一起正常工作的测试)。
   Pact 添加的内容是您的 CI 构建的新步骤。在构建期间，您应该使用 pact-provider-verifier，它接受消费者创建的协议(protocol)，针对您的提供者重播它，并将实际响应与协议(protocol)中定义的预期响应进行比较。这使您可以验证您的提供者是否可以实现消费者定义的预期交互。

2. 我认为多个提供者状态背后的主要思想是顺序和代码的可重用性。假设您的消费者定义了 2 个与以下提供者状态的交互:

   • “存在 ID 为 123 的用户，并且它有一个帖子”
   • “存在ID为123的用户，属于admin组”

   
   这两个状态之间共享一些逻辑，因此像这样设置提供者状态很快就会变得困惑。相反，将以下状态映射到分别设置每个状态的代码要好得多:

   • “存在 ID 为 123 的用户”
   • “用户 123 有一个帖子”
   • “用户123属于admin组”

3. 如果您回顾上面的示例，您会发现提供者现在与 ID 为 123 的用户非常耦合。如果消费者决定将其更改为 ID 456，这将破坏提供者设置执行。所以想法是将“123”作为参数传递，而不是在状态描述字符串中传递。该协议(protocol)将如下所示:

"providerStates": [{
  "name": "The user exists",
  "params": {"id" : 123}
}]

1. 文档中描述的语义版本控制只是一个建议和最佳实践。我认为您选择的任何版本控制策略都会起作用，甚至不必在服务/团队之间保持一致。