testing - 如何在小 cucumber 测试中平衡细节与业务需求？

Question

我有一个包含 3 个时间戳列的表:created_on、updated_on 和 applied_on。

前两个是你的想法。最后一个是一些相关的外部 Action 发生的时间戳。

我的业务用户正在编写测试。如果我更改代码中的某些细节，我不希望他们的测试失败。也就是说，业务测试应该是测试业务需求，而不是技术实现。

这里有一些小 cucumber :

Given we do all the setup for this example
When a row is created
Then created_on will be valid
And updated_on will be valid
And applied_on will be undefined
And created_on will equal updated_on

现在，这是完全合乎逻辑且有效的。并且可能是反模式。这是非常低级的；我们正在谈论特定的列名称。

拍摄 2:

Given we do all the setup for this example
When a row is created
Then the created and updated dates are the same
And applied_on will be undefined

也许是生意？我不知道。

最后，拿3:

Given we do all the setup for this example
When a row is created
Then the dates are appropriate for creation

Given we do all the setup for this example
When a row is updated
Then the dates are appropriate for update

Given we do all the setup for this example
When a row is acted upon
Then the applied date is set    

所以我们在这里看到了不同细节级别的小 cucumber 测试。单元测试和业务测试之间的界线在哪里？如果正在创建功能文件的非编码 QA 人员想要确保日期设置得“恰如其分”怎么办？

 Then the dates are appropriate for creation

足够有弹性，但这如何满足那些想要确保日期合理的人呢？当然，底层代码似乎可以工作。编码人员可以向测试人员保证步骤代码满足需求。但这如何安抚任何称职的 QA 人员呢？

Answer 1

您的场景都集中在您的表如何存储数据上。他们需要关注数据为何重要。使用 Cucumber 来测试数据是否已写入表中只是效率不高。您可以通过单元测试轻松地做到这一点，这将是

1. 更容易写
2. 运行成本更低

好的 cucumber 场景在更高的抽象层次上工作，因此每个场景都涵盖了大量的领域。这是您可以证明运行(并且在较小程度上)编写它们的费用合理的唯一方法。