我们在一个相当大的代码库中使用 cucumberJS，其中包含数百个 cucumber 场景，而且我们一直遇到步骤重用问题。
由于 Cucumber 中的所有步骤都是全局的，因此很难编写类似“并且我选择列表中的第一项”或类似的类似高级的步骤。我们最终不得不附加“在主页上”（所以：“我选择主页上文件夹列表中的第一项”），这感觉不对，而且读错了。
另外，我发现很难弄清楚步骤之间的依赖关系是什么。例如，我们使用“我看到”模式来存储world cucumber 实例上的页面对象引用，以便在后续步骤中使用。我觉得这很尴尬，因为在读取 .feature 文件时这些依赖项几乎是不可见的。
您对如何在大型团队中使用 Cucumber 有什么建议？ （包括“挖黄瓜改用”:)）
【问题讨论】：
标签： cucumber acceptance-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，而在于您在现有方案及其实施中所欠的债务。如果你想让事情有所改善，你必须偿还你的债务，祝你好运
【讨论】：