时间戳

首页 > 解决方案 > 在大型代码库/团队中重用黄瓜步骤

cucumber - 在大型代码库/团队中重用黄瓜步骤

问题描述

我们在具有数百个黄瓜场景的相当大的代码库上使用 cucumberJS，并且我们遇到了步骤重用的问题。

由于 Cucumber 中的所有步骤都是全局的，因此很难编写类似“并且我选择列表中的第一项”或类似的类似高级的步骤。我们最终不得不附加“在主页上”（所以：“我选择主页上文件夹列表中的第一项”），这只是感觉不对并且读错了。

此外，我发现很难弄清楚步骤之间的依赖关系是什么。例如，我们使用“我看到”模式来存储world黄瓜实例上的页面对象引用，以便在后续步骤中使用。我觉得这很尴尬，因为在读取.feature文件时这些依赖项几乎是不可见的。

您对如何在大型团队中使用 Cucumber 有什么建议？（包括“抛弃黄瓜，改用”:)）

标签： cucumberacceptance-testing

解决方案

写下关于你在做什么以及你为什么这样做的场景/步骤，而不是关于你如何做事。Cucumber 是一个做 BDD 的工具。这里的关键词是行为及其解释。Cucumber 和 steps 背后的基本思想是每个行为（什么）在应用程序中都有一个唯一的名称和位置，并且在应用程序上下文中，您可以使用该名称毫无歧义地谈论该行为。

因此，您的示例永远不应该分步进行，因为它们是关于您如何做某事的。好的步骤从不谈论点击或选择。相反，他们谈论您单击或选择的原因。

当您遵循此模式时，您最终会在更高的抽象级别上获得更少的步骤，每个步骤都专注于特定的主题。

这种模式很容易实现，并且比较容易维护。困难在于，要编写场景，您必须深刻理解自己在做什么以及为什么它很重要，这样您才能发现/发现清晰、清晰和简单地表达自己所需的语言。

我将给出关于登录的标准示例。我使用它是因为我们对登录是什么以及为什么它很重要有共同的理解。在您可以登录之前意识到您必须进行注册，这很复杂。

Scenario: Login
  Given I am registered
  When I login
  Then I should be logged in

这个的实现很有趣，因为我将所有工作委托给辅助方法

  Given I am registered
    @i = create_registered_user
  end

  When I login
    login_as(user: @i)
  end

  Then I should be logged in
    should_be_logged_in
  end

现在您的问题变成了管理辅助方法之一。你所拥有的是一个带有大量辅助方法的全局命名空间。现在这是一个代码和命名问题，您所要做的就是

  • 尽量减少辅助方法的数量
  • 保持每个辅助方法简单
  • 确保方法名称之间没有歧义
  • 确保没有重复

这仍然是一个难题，但是 - 它不像您正在处理的那样难 - 达到这一点有很多额外的好处 - 现在它是一个代码问题，很多人都有管理代码的经验。

您可以通过以下方式完成所有这些事情 - 命名规则（我上面的所有方法都以他们的名义登录） - 巧妙但受控地使用参数 - 频繁的重构和代码清理

您的辅助方法的代码将具有 - 在所有应用程序代码中流失率最高的 - 最需要简单明了

因此，目前您的问题不在于 Cucumber，而在于您对现有场景及其实施的债务。如果你想让事情有所改善，你必须偿还你的债务，祝你好运

推荐阅读