Cucumber 在大型代码库/团队中重用Cumber步骤

我们在一个相当大的代码库上使用cucumberJS，有数百个cucumber场景，我们遇到了步骤重用的问题

因为Cucumber中的所有步骤都是全局性的，所以很难编写这样的步骤，我选择列表中的第一项或类似项，这将是类似的高级步骤。我们最终不得不在主页上添加内容，所以：我在主页上的文件夹列表中选择了第一项，它感觉不对劲，读起来也不对

此外，我发现很难找出步骤之间的依赖关系。例如，我们使用一个和我看到的模式来存储WorldCumber实例上的页面对象引用，以便在以后的一些步骤中使用。我发现这很尴尬，因为在读取.feature文件时，这些依赖项几乎是不可见的

---

关于如何在大型团队中使用cucumber，你有什么建议？包括放弃黄瓜，改用：

写一些关于你正在做什么以及为什么要做的场景/步骤，而不是关于你是如何做的。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

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

尽量减少助手方法的数量 保持每个助手方法简单 确保方法名称之间没有歧义 确保没有重复 这仍然是一个难题，但是 -这并不像你所面对的那么困难 -达到这一点还有很多额外的好处 -现在这是一个代码问题，很多人都有管理代码的经验

你可以用电脑做所有这些事情 -命名规则我上面所有的方法都以自己的名字登录 -巧妙但有控制地使用论点 -频繁的重构和代码清理

助手方法的代码将具有 -您所有应用程序代码中最高的搅动量 -最大的需要是简单明了

因此，目前您的问题不是关于您对现有场景及其实现的债务。如果你想改善，你必须还清债务，祝你好运