Question

我的表格中有3个时间戳列：created_on，updated_on和applied_on。

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

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

这里有一些小黄瓜：

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

所以我们在这里看到不同细节水平的小黄瓜测试。单元测试和业务测试之间的界限在哪里？如果正在创建功能文件的非编码质量保证人员想要确定日期已设置，那该怎么办？＆＃39;

 Then the dates are appropriate for creation

足够有弹性，但是如何满足那些想要确定日期合理的人呢？当然，底层代码似乎有效。编码员可以向测试人员保证步骤代码满足要求的需要。但是，如何安抚任何QA人值得他们的盐？

Answer 1

您的方案都集中在表存储数据的方式上。他们需要关注数据为何重要。使用黄瓜来测试数据是否写入表只是没有效率。您可以使用单元测试轻松完成此操作，这将是

更容易编写
运行便宜得多

良好的黄瓜方案在更高的抽象级别上工作，因此每个方案都涵盖了大量的基础。这是你可以证明编写它们的运行费用（以及在较小程度上）的唯一方法。

如何在小黄瓜测试中平衡细节与业务需求？

1 个答案: