6

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

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

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

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

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

我认为 BDD 原则可能会说“是”，因为预期行为的沟通更加明确，但我不确定。这对我来说肯定有矫枉过正的感觉。这些场景可能是大量的复制粘贴，并进行了微小的更改。

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

4

2 回答 2

4

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

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

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

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

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

于 2012-09-25T15:12:24.883 回答
0

如果您正在重构场景，通常是通过从重复脚本中提取小表，那么维护成本可能根本不会伤害您。但是，这并不能解决执行时间成本的问题。

在这种情况下，我可能会建议自动化最简单的场景（没有客户）和最复杂的场景（许多客户匹配过滤器，但不是全部），并将其他排列留给更集中的程序员测试。我会包括“没有客户”的情况，只是因为人们倾向于把这个问题弄得很糟糕，比如偶尔会导致程序崩溃。（你没有运行种子数据脚本？！）

于 2012-09-25T16:42:11.333 回答