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

Posted 2023-02-23

【中文标题】我们如何处理 BDD 场景的小排列？

【英文标题】：How do we handle minor permutations of BDD scenarios?

【发布时间】：2012-09-24 17:47:44

【问题描述】：

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

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

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

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

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

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

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

【参考方案1】：

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

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

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

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

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

【讨论】：

谢谢，Liz，这很有帮助。我认为我们在这里遇到的陷阱仍然是考虑测试之类的行为。我们想要全面的测试，所以我们想要全面的场景。必须转变这种心态。另外，我在哪里可以了解更多关于这种“姜饼”图案的信息？除了一些不错的蛋糕食谱外，谷歌对我的帮助并不多……:)

@ryan-nelson Dan North 有望在某个点写一本书……除此之外，请观看他的视频。从本质上讲，您需要一些易于理解的软件（巧克力蛋糕）的配方，然后用其他东西替换您需要替换的部分（用姜代替巧克力）。您无需为厨师或开发人员解释整个食谱即可获得它。

在这里找到他解释的一个视频：oredev.org/2011/sessions/patterns-of-effective-delivery

我并不是说听起来轻率，但这对我来说听起来像是可重用性。几十年来，这一直是软件开发的圣杯？

@robin-green 对，除了它在分析中的可重用性，为此你需要假设开发人员不是白痴，并且剪切和粘贴可能没问题。由于几十年来软件开发一直把开发者当作白痴对待，它实际上可能有点革命性。去丹。

【参考方案2】：

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

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

【讨论】：

“鉴于您没有客户......您是什么意思，您没有客户？您是客户经理！您为什么还要尝试使用此程序？打电话并获得一些该死的客户！”