Question

我怀疑是否应该考虑某种类型的测试功能或合同。

假设我有一个类似/ getToolType的API，它接受{object“”myObject“}作为输入，并以{type：”[a-z] +“}

形式返回类型

客户端和服务器之间已经同意返回的类型将匹配一组字符串，让我们说[hammer | knife | screwdriver]，所以消费者决定在枚举中解析它们，当返回的类型时具有回退值不明。

消费者是否应该为每种类型（锤子，刀子，螺丝刀）包含一个测试用例，以确保生产者仍然遵循它将始终返回的协议，例如，当调用/ getToolType时，小写字符串“hammer”一个锤子对象？或者你会认为这样的测试用例是功能性的？为什么？

Answer 1

IMO简短的回答是“没有”＃。

合同测试对结构更感兴趣，如果我们开始对API进行边界测试，我们会进入功能测试[1]领域，这最好在提供者代码库中完成。您可以使用匹配器来确保只返回这三个值中的一个，这应该确保提供者构建不能返回其他值。

我会回应@J_A_X的评论 - 没有正确或错误的答案，只是要小心测试输入/输出数据的所有排列。

[1] https://docs.pact.io/best_practices/contract_tests_not_functional_tests.html

Answer 2

好问题。简短的回答：没有正确或错误的方式，只是你想要的方式。

更长的答案：

Pact（和合同测试）的目的是测试特定的场景并确保它们匹配。您可以简单地在合同中创建一个正则表达式，允许这些枚举的任何字符串类型，或者可能为null，但前提是您的消费者根本不关心该值。例如，如果工具类型有品牌，我不会关心品牌，只是因为我只是在消费者（前端）上逐字显示品牌，因此它会以字符串形式返回。

然而，如果由我自己决定，根据我对你的场景的理解，考虑到它所击中的端点，似乎工具类型实际上非常重要，因此我可能会对每个枚举进行特定的测试和合同确保我的消费者的那些特定场景是有效的（我用某些东西调用X，我希望Y有工具类型Z）。

这两种解决方案都是有效的，它归结为：您认为特定的工具类型对消费者很重要吗？如果是，创建特定于它的合同，如果没有，那么只需创建一个通用合同。

希望有所帮助。

Answer 3

正确的状态是消费者消费锤子、刀子和螺丝刀，简称c=(hammer,knife,screwdriver)，而生产者生产锤子、刀子和螺丝刀，p=(hammer,knife,screwdriver)。有四种回归场景：

c=(锤子,刀,螺丝刀,剑), p=(锤子,刀,螺丝刀)
c=(锤子,刀,螺丝刀), p=(锤子,刀,螺丝刀,剑)
c=(锤子,刀,螺丝刀), p=(锤子,刀)
c=(锤子，刀)，p=(锤子，刀，螺丝刀)

1 和 3 以一种非常温和的方式打破了合同。在第一个场景中，客户声明了生产者（尚）不支持的新类型。在第三种情况下，生产者停止支持一个类型。场景的严重性当然可能很谨慎，因为我认为软回归可能存在于关键业务流程中的某个服务中。但是，如果它很关键，那么就有很大的动机用专门的测试用例来覆盖它。第 2 和第 4 种情况更严重，在这两种情况下，消费者最终可能会出现错误，例如可能无法反序列化数据。

拥有每种类型的测试用例应该可以检测场景 3 和 4。在第一种情况下，它可能会触发开发人员创建一个额外的测试用例，该用例将在生产者站点上失败。但是，测试用例对第二种情况无能为力。因此，尽管成本相对较高，但这种策略并没有为我们提供完整的测试覆盖率。

拥有一个带有正则表达式的测试用例，涵盖所有有效类型（即锤子|刀|螺丝刀）应该是消费者开发人员在第 1 和第 4 种情况下重新设计测试用例的有力触发因素。一旦正则表达式被调整为新的消费者能力，它就可以检测到概率 p=1/3 的场景 4（即如果生产者选择螺丝刀作为样本值，则测试将失败）。即使没有正则表达式调整，它也会检测到 p=1/3 的第三种情况。这种策略对于第一种和第二种情况是无能为力的。

然而，在正则表达式之上，我们可以做更多的事情。也就是说，我们可以设计随机数据的生产者测试用例。假设所讨论的类型定义如下：

enum Tool {hammer,knife,screwdriver}

我们可以渲染测试数据：

responseBody = Arranger.some(Tool.class);

这段代码使用了 test-arranger，但还有其他库也可以这样做。它选择有效的枚举值之一。每次都可以是不同的。它有什么变化？现在我们可以检测到第 2 种情况，并在调整正则表达式后检测到第 4 种情况。所以它涵盖了最严重的情况。还有一个缺点需要考虑。生产者测试是不确定的，取决于绘制的值，它可以成功或失败，这被认为是一种反模式。尽管被测试的代码是正确的，但当某些测试有时会失败时，人们开始忽略测试的结果。请注意，带有随机数据的生产者测试用例并非如此，事实恰恰相反。尽管测试的代码不正确，它有时也能成功。它仍然远非完美，但这是一个有趣的权衡，因为它是第一个设法解决非常严重的第二种情况的策略。

我的建议是使用 带有随机数据的生产者测试用例，并在客户端使用正则表达式。尽管如此，没有完美的解决方案，您应该始终考虑什么对您的服务很重要。具体来说，如果消费者可以放心地忽略未知值，那么推荐的方法可能并不完美。

我应该测试合同中的所有枚举值吗？

3 个答案: