黄瓜采用的陷阱

行为驱动开发 （或BDD）及其支持工具似乎在Java世界中获得了空前强大的发展势头。 作为用于支持BDD和使其自动化的最受欢迎的框架之一， Cucumber似乎是在不考虑采用这种工具的含义的情况下为用户验收测试（或UAT）提供支持的首选框架。 由于使用Cucumber是我一直在从事的项目之一的要求，因此我想分享一下我所做的一些观察，并描述这种决策的一些陷阱。

我们现在在哪？

在介绍我的观察之前，我想指出互联网上来自不同来源的明显挫败感。 仅举一个例子 ，请查看一下David Heinemeier Hansson （Ruby on Rails的创建者） 的TSA之类的测试 ，其中他提到了与测试过程有关的某些危险信号，并将其总结在“七不测试”列表中'：

6.除非您生活在非程序员写作测试的魔幻王国中，否则请不要使用Cucumber（如果在那里，请给我送一瓶仙尘！）

这只是许多对采用黄瓜的结果感到失望的人之一。 但公平地说，有些人实际上生活在魔术王国中，并对BDD和Cucumber感到满意。 只需考虑丽莎·克拉克 （ Lisa Clark）在她的王国“ 黄瓜善良 ”上发表的文章。

我们应该在哪里？

所有这些表明，有一种方法可以获取BDD的那些神话般的好处，但是采用Cucumber作为UAT框架远远不够。 让我们停下来思考一下理想的情况。 BDD的核心原则是什么？黄瓜如何适应所有这些原则。 让我们从AslakHellesøy的博客帖子开始，标题为“世界上最容易被误解的协作工具” 。 他指出有关黄瓜的起源：

Cucumber是出于对模棱两可的要求和订购软件的人与交付软件的人之间的误解而产生的。

他和他的同事们以为他们找到了解决之道。 这个想法是将自动验收测试，功能要求和软件文档组合成一种非技术人员和测试工具可以理解的格式。 但是，许多人误解了这个想法，或者只是认为成功有捷径，足以在Cucumber中实现功能，仅此而已。 哦，男孩，他们错了！

不幸的是，您不能只下载Cucumber，开始编写Cucumber Features，并期望真理和启蒙的奇迹会自己发生。 需要遵循的过程涉及软件团队中的许多角色。 此过程称为BDD。 这就是我提到的那种集团。 BDD不是您可以下载的工具。 Gojko Adzic为BDD提供了一个更好的新名称： Specification by Example 。

在我看来，这是最大的问题–组织和团队在没有更深入地了解好处，成功实施此更改的必要条件以及此决定的陷阱的情况下采用工具而非流程。

这使我进入了理想状态-魔法王国。 正如Lisa和Aslak所指出的那样，此过程不仅供程序员编写“他们的”测试。 它们只是BDD中发生的事情的一部分。 Aslak概述了此过程的两个核心活动：

• 需求定义
  • 这通常是业务分析师，程序员和测试人员坐下来讨论需要实现哪些功能的会议。
• 由内而外的发展
  • 这是TDD所熟知的一种做法，在这种情况下，失败的测试会驱动下一步需要执行的操作。

黄瓜采用的陷阱是什么？

这是我们需要提出一些棘手问题的部分。 让我们看看成功实现BDD并使用Cucumber写下规范必须避免的陷阱。 这些顺序不是特定的，因为我不想暗示一个比另一个更重要。 它们都会对测试和整个开发过程产生负面影响。

我们只是在追随当前趋势吗？

黄瓜是一个框架，通常被认为是货运崇拜编程的一个很好的例子。 您可以尝试确定一项很好的测试，以确定您的组织是否参与了“货物崇拜”编程，是问负责黄瓜采用的人员，例如“我们为什么还要考虑这种测试框架和方法？” 如果这个问题的答案是“因为有人/每个人都这样做”。 或一些废话，这是一个危险信号。 如果组织或团队不准备采用该过程，则仅采用支持工具会使情况变得更糟。

不能保证像Cucumber这样的工具本身就能帮助开发人员获得对业务领域的更深刻见解或改善他们，业务分析师和测试人员之间的沟通。 这是该过程需要促进的。 黄瓜在这方面没有什么可做的。

这真的很适合文化/客户吗？

对于采用该技术至关重要的另一件事是BDD和Cucumber如何适应您的文化以及您的客户开展业务的领域。让我们在家中开始。 由于Cucumber只是一种支持工具，因此组织需要准备好分配适当的资源来首先实施该流程，然后再逐步使用Cucumber。 但是，由于Cucumber使用Gherkin来捕获规范，因此对于某些程序员来说，用“英语”表达测试条件可能会比较麻烦，而不是使用更常见的编写测试方式。 乔恩·阿彻（Jon Archer）有一篇很棒的文章，题为《 如何在BDD上彻底失败》 ，作者描述了他在组织中推动BDD的经验。 他详细介绍了团队的反应方式以及在此过程中面临的挑战。

因此，您的团队和组织已准备好完全采用BDD，您是否迫不及待地开始规范会议并写下这些功能？ 这是一个好的开始，但是您还需要考虑客户及其需求。 您能想象成为一名企业主并且必须阅读许多Gherkin功能吗？ 特别是当它们的细节，范围和质量有所不同时？ 我不这么认为。 一些客户端可能需要访问这些功能，其中一些甚至可能会从此访问中受益。 但是在走这条路之前，您应该确保确实可交付使用，并且它还为过程质量以及产品本身增加了价值。

适当的详细程度是多少？

好，让我们将重点转移到功能本身上。 在您的团队编写了至少两个功能之后，您可能会注意到每种方案所涉及的详细程度有所不同。 当您仅采用框架（无过程）时，尤其如此。 在不涉及任何交流的情况下，您的功能将根据作者，对手边功能的理解甚至对细节的关注而有所不同。

我见过的大多数功能文件都比需要的详细得多。 在我看来，这会导致功能膨胀（以及步骤定义），并降低团队和客户的价值。 BDD的早期采用者之一Elizabeth Keogh考虑到利益相关者的观点，是一个很好的案例：

如果您的场景以“当用户在“搜索”文本框中输入“蓝精灵”…”开头时，则级别太低了。 但是，即使“当用户在购物篮中添加“蓝精灵”，然后去结帐，然后为商品付款”时，也太低级了。 考虑一下您的业务能力。 它允许您的用户做什么？ 利益相关者从中获得什么价值？ 它实际上是如何赚钱的？ 您正在寻找类似“当用户购买蓝精灵时”的信息。

应该测试什么？

好家伙。 我相信这是程序员可以拥有的最有价值的技能之一。 能够判断应该测试什么，不需要测试什么。 再加上能够确定测试行为的某些方面所需的测试类型的能力，使一个优秀的程序员成为可能。 这是我在使用Cucumber时遇到的最大问题之一。 在用户接受度测试水平上测试几乎所有内容的压力完全忽略了UAT的范围。

无法正确管理测试范围和这些测试的每种类型的目的，通常会导致缓慢而脆弱的功能充满了模拟，复杂的解决方法以及许多不必要的步骤定义。 在极端情况下，您可能最终会为被测应用程序的每个新方面创建自定义解决方案，从而使框架难以使用且难以使用。

有什么可以重用的吗？

谁知道。 BDD将重点放在沟通上，如果沟通不畅，不良的事情就会开始发生。 很容易忽略Paul已经创建了您当前正在使用的步骤定义。 或者，您只是为登录页面选择了其他名称。 这样的事情发生了。 缺乏沟通会直接导致步骤定义过大，并且当两个看似相同的步骤执行一些额外的操作时，可能会导致行为差异。

我现在将以我的个人经验来谈谈，但是我认为测试应该是表达性和明确性的，通常会降低重用的可能性（例如，为了易于阅读而重复自己）。 与更详细，集成样式的功能（通常以“给我以'用户'和'密码'签名”开始）相比，这再加上我偏爱不太详细的功能会减少重复使用。 请记住，所有步骤始终可以全局访问。 但是，无论您选择实施哪种样式，无论哪种方式，都存在重用潜力。

这些甚至是验收测试吗？

是的，这也是您需要提出的问题之一。 许多开发人员关注行为的所有可能方面，而不是关注给用户带来的给定功能带来的价值。 资深博客作者和开发人员Jack Kinsella这样说：

尽管有其他看法，但大多数程序员从未编写过一个验收测试。 相反，他们使用Cucumber语法编写了集成测试。

我完全同意。 根据我在项目中所看到的内容以及GitHub上的一些开源项目，集成测试方法似乎在其功能文件中非常普遍。

我们的IDE支持Cucumber吗？

现在，让我们集中讨论实际创建特征文件有多难。 由于我是Java程序员，所以我只能说说我个人经历的内容。 在IntelliJ IDEA和Eclipse上都使用Cucumber JVM时，我可以肯定地说用户体验各不相同。 因为我还没有使用过其他IDE，所以我不能代表他们，但是有一点可以肯定– IDE提供了各种级别的支持。 确保您团队的首选IDE支持Cucumber和Gherkin，因为对这种语言以及Cucumber框架的支持确实起了很大的作用。

我们要花多少钱？

再一次，由于缺少该过程，而剩下的只是Cucumber，以这种方式进行测试的过程成本很高。 最后一点受以上几乎所有要点的影响，而且还受到“不加BDD做法”的“黄瓜浸红”程度的影响。 此外，维护和重构（在应用程序发生更改的情况下）要困难一些，与其他测试方法相比，您最终将花费更多的时间。 这里要考虑的最后一件事是您所处的环境。在敏捷环境中事情确实会发生变化。 并且，如果您已经为受影响的功能编写了功能文件，而这些功能是意外更改，那么最终您将无法完成所有工作。

最后的想法

这是我目前在职业生涯中可以分享的一切。 尽管我在这里讨论并遇到了许多问题，但我相信BDD和Cucumber可以正常工作。 关键在于人员及其对流程和支持该流程的框架的理解。 老实说，我很想发现自己生活在魔幻王国中。 但是到目前为止还没有发生，所以我仍然希望:)。

在Internet上有一个术语被广泛使用，它可以掩盖我在本文中所描述的症状-陷入黄瓜测试陷阱。 如果您已经做到了这一点，请确保不要重复犯过许多其他错误。 进入黄瓜测试陷阱很容易，但是恢复起来又困难又昂贵。 认识到流程和支持框架之间的区别，不要寻求捷径。

让我在本文的结尾用释义： 泰勒 ·杜顿（ Tyler Durden） （戴维·芬奇斯电影《搏击俱乐部》中的角色）来描述当框架变得比导致其创建的思想更重要时会发生什么： 应该驱动实现的功能最终会反映出来。

翻译自: https://www.javacodegeeks.com/2015/04/pitfalls-of-cucumber-adoption.html