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

Question

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

假设我有一个像 /getToolType 这样的 API，它接受一个 {object" "myObject"} 作为输入，并以 {type: "[az]+"} 的形式返回 type

客户端和服务器之间一致认为返回的类型将匹配一组字符串，比如 [hammer|knife|screwdriver]，所以消费者决定在枚举中解析它们，当返回的类型未知时使用回退值。

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

Answer 1

IMO 的简短回答是“不”。

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

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

Answer 2

很好的问题。简短的回答：没有正确或错误的方法，只有你想怎么做。

更长的答案：

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

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

这两种解决方案都是有效的，归根结底是：您认为特定的工具类型对消费者重要吗？如果是，则创建特定的合同，如果不是，则仅创建通用合同。

希望有帮助。