我喜欢 BDD 开发方法，但我遇到了一个问题，即该方法能走多远。这条来自 ThoughtWorks 的最新评论Radar http://thoughtworks.fileburst.com/assets/thoughtworks-tech-radar-march-2012-us-color.pdf让我停顿一下：
“像 Cucumber 这样的行为驱动设计 (BDD) 测试框架的出现，与像 Selenium 这样的浏览器自动化工具相结合，鼓励了在浏览器级别广泛使用验收测试。不幸的是，这鼓励了在运行成本高昂的情况下进行大量测试。测试是最大的，我们应该在适当的级别进行测试，尽可能贴近代码，这样测试才能以最高的效率运行。浏览器级别的测试应该是锦上添花，有验收和单元的支持在适当的层执行测试。”
这是我的场景（双关语）：
我有一个基本的 CRUD 应用程序，其业务要求是根据允许最终用户选择的条件过滤显示的数据。为了便于讨论，我们假设这是一个电力公司的应用程序，我正在显示每个客户当前本月至今的用电量。此应用程序的用户可以通过选择单个客户、多个客户、无客户或“所有客户”来缩小数据范围。显示的数据将根据他们的选择而变化。
对于产品利益相关者来说，这些实际上代表了 4 个不同的场景。然而，从开发人员的角度来看，它们实际上是相同的，唯一的区别是传递给数据库的参数。所以问题就变成了：阐明每种排列的好处是否超过运行和维护它们的成本？
我认为 BDD 原则可能会说“是”，因为预期行为的传达更加明确，但我不确定。这对我来说确实有一种矫枉过正的感觉。这些场景可能是大量的复制粘贴和微小的更改。
我倾向于用一个捕获核心业务价值的场景来涵盖此功能（“当我选择客户时，我会看到用电量数据”），然后用一组非基于 UI 的集成测试来涵盖其他排列验证服务/查询返回正确的数据。这种想法有错吗？在不放弃 BDD 优势的情况下，确保涵盖这些场景的最佳答案是什么？
我对 BDD 的规则是，开发人员应该能够轻松地从所描述的任何行为中导出场景，如果不能，则用场景来说明行为。
当 BDD 描述棘手的事情时，它是最有用的。要么向开发人员传递专业知识，要么缩小行为范围，直到发现不确定性。在具有基本过滤器的 CRUD 应用程序中，行为非常容易理解。
你所描述的可能最好地涵盖了丹·诺斯的“姜饼”模式：采用其他东西的配方，但行为的一个方面与另一个方面不同（或者在这种情况下，行为的一个额外的、易于理解的方面） ）。他还使用了一点复制粘贴，我特别怀疑这种行为。
所以，你的倾向是完全正确的。如果自动化，我可能只会自动化一个示例，让单元测试和集成测试覆盖其余部分。
我还想知道为什么要进行这个项目。必须有某物有趣的是，否则它不会发生。找到它，它可能是开始讨论场景的好地方。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
