bdd - 我们如何处理 BDD 场景的细微排列？

Question

我很喜欢 BDD 的开发方法，但我遇到了对走多远的担忧。这条来自 ThoughtWorks 的最新评论 Radar让我暂停:

"The advent of behavior-driven design (BDD) testing frameworks like Cucumber, combined with browser automation tools like Selenium, has encouraged widespread use of acceptance testing at the browser level. This unfortunately encouraged doing the bulk of testing where the cost to run the tests is the greatest. Instead, we should test at the appropriate level, as close to the code as possible, so that tests can be run with maximum efficiency. Browser-level tests should be the icing on the cake, supported by acceptance and unit tests executed at appropriate layers."

所以这是我的场景(双关语):

我有一个基本的 CRUD 应用程序，其业务要求是根据允许最终用户选择的条件过滤显示的数据。为了便于讨论，假设它是电力公司的应用程序，我正在显示每个客户的当前月至今用电量。此应用程序的用户可以通过选择单个客户、多个客户、无客户或“所有客户”来缩小数据范围。显示的数据将根据他们选择的内容而变化。

对于产品利益相关者来说，这些实际上代表了 4 个不同的场景。然而，从开发人员的角度来看，它们实际上是相同的，唯一的区别是传递给数据库的参数。所以问题就变成了:列出每个排列的好处是否超过了运行和维护它们的成本？

我认为 BDD 原则可能会说"is"，因为预期行为的交流更加明确，但我不确定。它对我来说当然有一种矫枉过正的感觉。这些场景可能是大量的复制粘贴，并进行了细微的更改。

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

Answer 1

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

BDD 在描述棘手的事情时最有用。无论是将专业知识传递给开发人员，还是缩小行为范围，直到发现不确定性。在带有基本过滤器的 CRUD 应用程序中，行为真的很容易理解。

您所描述的可能最好地涵盖了 Dan North 的“ Gingerbread ”模式:采用其他方法，但行为的一个方面与另一个方面不同(或者在这种情况下，行为的一个额外的、易于理解的方面)。他也有点使用复制粘贴，我特别怀疑这种行为。

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

我也想知道为什么要进行这个项目。它必须有一些有趣的东西，否则它就不会发生。找到它，它可能是开始讨论场景的好地方。