黄瓜采用的陷阱

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

我们现在在哪/h2>

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

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

我们应该在哪里/h2>

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

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

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

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

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

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

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

黄瓜采用的陷阱是什么/h2>

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

我们只是在追随当前趋势吗/h2>

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

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

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

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

适当的详细程度是多少/h2>

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

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

应该测试什么/h2>

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

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

有什么可以重用的吗/h2>

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

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

这些甚至是验收测试吗/h2>

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

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

我们的IDE支持Cucumber吗/h2>

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

我们要花多少钱/h2>

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

最后的想法

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

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

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91435 人正在系统学习中 相关资源：KK录像机-瓜