关于协议使用的概念问题

问题描述 投票：1回答：3

我是一个团队的一员，为我们整个公司“开拓”协议的使用。在这次旅程中，我们面临许多问题，这些问题主要是由于误解了CDC测试协议的使用。很多问题可以随着时间的推移而得到解决，但仍有一些主要问题我无法找到任何好的解决方案或示例。由于我认为回答这些问题非常重要，我认为试图直接与您联系可能会对我们有所帮助。

  1. 问题：在实现提供程序测试时，我们应该在应用程序的“层”实现我们的测试吗？ 背景：当我们第一次开始使用pact向我们的应用程序添加CDC测试时，我们通过启动包含内存数据库的应用程序上下文来完成功能测试，并在此数据库中设置数据。这导致了难以维护的测试，另外我们实际上正在进行功能测试，而协议并不适用于此。在过度思考我们想要多次实现测试的方法之后，我们最终只测试了包含其余接口和（最好）输入和输出验证的边界。
  2. 问题：使用多个提供者状态背后的想法是什么？ 背景：Pact支持使用多个提供者状态进行一次交互。我们尝试了这个功能，但是很多开发人员并不认为多个提供商状态有很大的优势。因此，很多我们使用pact的cdc测试都有长而复杂的描述提供者状态。所以我认为我们不了解这个功能的基本概念。
  3. 问题：参数化提供者状态背后的想法是什么？ 背景：基本上和以前一样背景。我们尝试了这个功能，但很多开发人员决定不使用它。因为对该功能的拒绝是基于完全不了解该功能，所以我想知道该功能被认为是用于什么。
  4. 问题：我们应如何处理有关版本控制策略的协议？ 背景：目前，官方pact documentation中记录了处理具有语义版本控制的应用程序之间的合同。我们使用SNAPSHOT版本控制，目前无法更改版本控制策略。此外，我们公司的其他多个团队都有不同的版本控制策略。基本上，一般来说，不可能对一种策略进行协商。当我们谈论在整个公司中使用cdc和pact时，这意味着什么？这可能导致什么问题？是否正确标记合同（主要，功能，开发，生产......）解决有关版本控制的任何问题？
java spring-boot pact pact-jvm greybox
3个回答
3
投票
  1. 您的提供者测试不应受Pact的影响。您应该继续编写单元测试和功能集成测试（通过集成，我的意思是测试，确保服务中的不同组件一起正常工作）。 Pact添加的内容是CI构建的新步骤。在构建期间，您应该使用pact-provider-verifier，它接受消费者创建的协议，将其重放给您的提供者，并将实际响应与协议中定义的预期响应进行比较。这使您可以验证您的提供程序是否可以满足使用者定义的预期交互。
  2. 我认为多个提供者状态背后的主要思想是订单和代码可重用性。想象一下，您的消费者定义了与以下提供者状态的2次交互： “存在ID为123的用户，它有一个帖子” “存在ID为123的用户，它属于管理员组” 这两种状态在它们之间共享一些逻辑，因此像这样建立提供者状态可能会很快变得混乱。相反，将以下状态映射到分别设置每个状态的代码更好： “存在ID为123的用户” “用户123有一个帖子” “用户123属于管理员组”
  3. 如果回顾上面的示例，您将看到提供程序现在与ID为123的用户非常耦合。如果消费者决定将其更改为ID 456，那将破坏提供程序设置实现。因此，我们的想法是将“123”作为参数传递，而不是传递给状态描述字符串。该协议将看起来像这样：
"providerStates": [{
  "name": "The user exists",
  "params": {"id" : 123}
}]
  1. 文档中描述的语义版本控制只是一种推荐和最佳实践。我认为您选择的任何版本控制策略都可以工作，甚至不需要在服务/团队之间保持一致。
2
投票

除了西蒙的回答：

  1. 如果你看一下测试金字塔，pact测试就位于单元测试和集成测试之间。但是，如果你可以将它们推入单位空间，它们就会变得更容易维护。当我编写接触测试时，我会专注于联系人，以确保它没有做更多。
  2. 西蒙回答了2和3。多个提供者状态的真正原因是有人要求它。我不使用它们，一个对我来说总是足够的。
  3. 再一次，正如西蒙的回答。我们引入了参数，因为我们注意到消费者和提供者测试之间存在测试数据耦合。消费者使用的数据必须与提供者状态中的数据匹配，因此提供者生成的响应与消费者相关。这使得脆弱的测试。在参数之前，必须将数据编码到描述中以打破耦合。我编写了许多提供程序状态方法，这些方法在描述上运行正则表达式以提取数据。
  4. 唯一的要求是为消费者和提供者提供唯一的版本。他们不必使用相同的方案。每个已发布的协议都需要可识别，以及已发布的提供商验证结果。版本也需要是顺序的，因此代理可以告诉较旧的版本。语义版本控制非常适合。时间戳也可以在这里工作。不那么容易阅读。
2
投票

首先，我想说，你主动为你的整个公司试用Pact很棒:)

我们正在努力改进我们传达Pact的方式，因为我们知道解决这个问题并将其转发给其他开发人员并不是一个简单的问题。您可以提出任何改进文档/网站的建议，我们将不胜感激。

现在，关于问题：

在实现提供程序测试时，我们应该在应用程序的“层”实现我们的测试吗？

Pact本质上试图替换/增强集成测试，或者某些人会考虑提供者方面的功能测试。然而，对于某些公司/团队而言，这种命名法并没有真正好转，因为有些人会使用“功能”测试作为通过浏览器进行端到端测试。

从本质上讲，Pact可以替换您过去以特定方式攻击提供者的任何测试，然后验证输出，因为这基本上是Pact所做的;这样做的主要优点在于，它不是基于提供商的开发者认为那些输入/输出应该是什么，而是强调消费者实际使用它的方式。

问题：使用多个提供者状态背后的想法是什么？

正如Simon所说，多个提供者状态只是促进数据重用和防止开发人员一遍又一遍地重做样板代码的一种方式。它本质上只是一种以可重复的方式设置数据所需的方式，而不是浪费时间为每个单独的状态创建数据。话虽如此，有时您的提供商很简单，根本不需要此功能。

问题：参数化提供者状态背后的想法是什么？

参数是一种将一些可变数据注入状态的快速简便方法，如ID，交互可能需要准确检查ID是否完全相同，或者您还可以将其用于多个状态以创建特定情况，比如“使用id X创建用户”，然后“禁用ID为X的用户”。

问题：我们应如何处理有关版本控制策略的协议？

Pact提到了处理版本控制的最佳实践，即语义版本控制;它一直是理解用户是否更新其代码/依赖项，如果它是修复，添加或破坏的一种很好的方式。

但是，Pact并没有丝毫执行这一点，而是由你自己决定如何做到这一点。最后，在经纪人方面，合约只是用字符串“标记”。话虽如此，您可能想要整合您的策略，因为这不仅会影响提供商，还会影响消费者，因此需要更高程度的协作。

我希望这些回答你所有的问题。正如您所看到的，Pact对于不同的用例和策略是相当开放的，因为我们知道不是每个人都以相同的方式工作，但同时，它更加强调用户以确保他们有效地协作并设置所有人都可以使用的标准，否则它可能会变得混乱。可以说，契约给你足够的绳索让自己挂起来。

干杯，

中号

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.