我们如何处理BDD场景的小排列？

Question

我喜欢BDD开发方法，但我遇到了一个问题，那就是要走多远。来自ThoughtWorks最新雷达的这条评论让我停顿了一下：

“像Cucumber这样的行为驱动设计(BDD)测试框架的出现，加上像Selenium这样的浏览器自动化工具，鼓励了在浏览器级别广泛使用验收测试。不幸的是，这鼓励了在运行测试的成本最大的地方进行大部分测试。相反，我们应该在适当的级别进行测试，尽可能接近代码，这样测试才能以最大的效率运行。浏览器级别的测试应该是锦上添花，由验收和在适当的层执行的单元测试支持。”

所以我的场景是这样的（双关语）：

我有一个基本的CRUD应用程序，它有一个业务需求，可以根据允许最终用户选择的标准过滤显示的数据。为了便于讨论，让我们假设这是一个电力公司的应用程序，我将显示每个客户每月的电力使用情况。该应用程序的用户可以通过选择单个客户、多个客户、无客户或“所有客户”来缩小数据范围。显示的数据将根据他们选择的内容而改变。

对于一个产品涉众来说，这些实际上代表了4种不同的场景。然而，从开发人员的角度来看，它们实际上是相同的，唯一的区别是传递给DB的参数。所以问题就变成了：对每个置换进行拼写的好处是否超过了运行和维护它们的成本？

我认为BDD原则可能会说“是”，因为预期行为的通信更加明确，但我不确定。对我来说，这确实有一种矫枉过正的感觉。这些场景可能是大量的复制-粘贴，只需稍作改动。

我倾向于用一个捕获核心业务价值的场景来覆盖这个功能（“当我选择一个客户时，我会看到电源使用数据”），然后用一组非基于UI的集成测试来覆盖其他排列，这些测试验证返回正确数据的服务/查询。这样的思路是不是错了？在不放弃BDD的好处的情况下，确保覆盖这些场景的最佳答案是什么？

Answer 1

我对BDD的规则是，开发人员应该能够很容易地从描述的任何行为中导出场景，如果他们不能，就用场景来说明行为。

BDD在描述棘手的事情时是最有用的；或者在将专家知识传递给开发人员时，或者在发现不确定性之前缩小行为范围。在一个带有基本过滤器的CRUD应用程序中，行为确实很容易理解。

你所描述的可能是Dan North的“姜饼”模式的最佳描述：选择其他方法，但行为的一个方面与另一个不同（或者在这种情况下，行为的一个额外的、易于理解的方面）。他也使用复制粘贴的一点，我特别怀疑这种行为。

所以，你的倾向是完全正确的。如果要自动化，我可能只自动化一个例子，让单元和集成测试覆盖其余的。

我也想知道为什么这个项目被追求。一定有什么有趣的东西，否则就不会发生。找到它，它可能是一个很好的地方开始讨论场景。