我们在一个相当大的代码库上使用cucumberJS，有数百个cucumber场景，我们遇到了步骤重用的问题。
由于Cucumber中的所有步骤都是全局的，所以很难写出类似"我选择列表中的第一个项目"或类似的高级步骤。我们最终不得不附加"在主页上"(所以："我在主页上的文件夹列表中选择第一个项目")，这感觉不对，读起来也不对。
此外，我发现很难弄清楚步骤之间的依赖关系是什么。例如，我们使用"and I see"模式在world黄瓜实例上存储页面对象引用，以便在稍后的一些步骤中使用。我觉得这很尴尬，因为在读取.feature文件时，这些依赖关系几乎是不可见的。
关于如何在一个大团队中使用黄瓜，你有什么建议？(包括"抛弃黄瓜并改用"：)
编写关于你正在做什么以及为什么要做的场景/步骤，而不是关于你如何做事。黄瓜是做BDD的工具。这里的关键词是行为及其解释。Cucumber和步骤背后的基本思想是，每个行为(what)在应用程序中都有一个唯一的名称和位置，在应用程序上下文中，您可以使用该名称谈论该行为，而不会产生歧义。
所以你的例子永远不应该是循序渐进的，因为它们是关于你如何做某事的。好的步骤从不谈论点击或选择。相反，他们会谈论你点击或选择的原因。
当你遵循这种模式时，你会在更高的抽象级别上得到更少的步骤，每个步骤都集中在一个特定的主题上。
这种模式易于实现，维护起来也比较容易。困难在于，要写场景，你必须深刻理解你在做什么，以及为什么它很重要，这样你才能发现/揭示你需要的语言，从而清晰、清晰、简单地表达自己。
我将给出关于登录的标准示例。我使用这个是因为我们对什么是登录以及为什么它很重要有着共同的理解。在登录之前要意识到，你必须注册，这很复杂。
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
现在，您的问题变成了管理助手方法。您所拥有的是一个具有大量辅助方法的全局命名空间。这现在是一个代码和命名问题，你所要做的就是
- 尽量减少辅助方法的数量
- 保持每个helper方法的简单性
- 确保方法名称之间没有歧义
- 确保没有重复
这仍然是一个难题，但是-它不像你正在处理的那样难-达到这一点还有很多额外的好处-现在这是一个代码问题，很多人都有管理代码的经验。
你可以用-命名规则(我上面所有的方法都以它们的名字登录)-巧妙但有控制地使用论据-频繁重构和代码清理
助手方法的代码将具有-所有应用程序代码的最高流失率-最需要的是简单明了的
所以目前你的问题不是关于Cucumber，而是关于你现有场景及其实现的债务。如果你想改善情况，你必须偿还债务，祝好运