我们正在使用pact进行合同测试。对于在两个不同上下文中使用的 api,将在响应中使用不同的值进行响应(尽管响应的字段和格式是相同的。)我们是否应该将其作为两种不同的交互来覆盖?如果是,这不是测试业务功能吗?
这也会对以下情况产生影响...... 我们正在使用合同测试来验证我们的移动应用程序的向后兼容性。如果 api 发生了变化,则只有响应的值发生了变化。如果更改适用于当前版本的消费者,但不适用于旧版本。这将破坏提供商与旧版本移动应用程序的向后兼容性。如果我们只将响应的结构视为合同测试的一部分,我们将如何捕捉到这一点?
答案 0 :(得分:3)
这是一个很好的问题,在所有情况下都没有直接的答案。
对此我要说的第一件事是,结构本身并不是契约测试 - 它更像是模式测试 - 和 schemas are not contracts。在很多情况下,契约测试确实关心值。
首先使用以下 operative:
<块引用>确定测试什么或不测试什么的经验法则是 - 如果我不包括这个场景,消费者中的什么错误或对提供者如何响应的误解可能会被遗漏。如果答案是否定的,请不要包含它。
在您的情况下, role
的值具有特定的类似枚举的含义。我假设消费者代码寻找这个值,并且可能根据它的值有条件地做一些不同的事情。例如,如果它是一个 UI,它可能会在页面旁边显示不同的选项,或获取其他相关数据。
如果是这种情况,那么您可能希望将其作为合同测试包含在内。如果 UI 不关心字段的值而不是显示它,那么它wouldn't be worth 包括在合同测试中
<块引用>如果是,这不是像测试业务功能吗?
嗯,不完全是。契约测试不是功能测试,但与许多类型的测试一样,存在重叠。您在这里的目标是确保涵盖消费者和提供者之间预期发生的各种重要对话。功能测试是一种separate activity,主要可以通过其对副作用的关注来区分。