Question

我们在具有数百个黄瓜方案的相当大的代码库上使用CucumingJS，并且一直遇到步骤重用的问题。

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

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

在大型团队中如何使用黄瓜的秘诀是什么？（包括“沟黄瓜并代替”：））

Answer 1

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

因此，您的示例不应步步为营，因为它们与您如何做某事有关。好的步骤永远不要谈论单击或选择。相反，他们谈论您单击或选择的原因。

当您遵循此模式时，您将在较高的抽象级别上减少步骤，而每个步骤都专注于特定主题。

此模式易于实现，并且适度易于维护。困难在于编写场景时，您必须对自己的工作及其重要性具有深刻的理解，这样才能发现/发现表达，清晰，简单地表达自己的语言。

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

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

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

保持尽可能少的辅助方法
使每种帮助方法保持简单
确保方法名称之间没有歧义
确保没有重复

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

您可以使用以下方法完成所有这些操作 -命名学科（我上面所有的方法都以其名称登录） -巧妙但受控地使用参数 -频繁进行重构和代码清理

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

因此，当前您的问题不是与黄瓜有关，而是与现有方案及其实施有关的债务。如果您想改善情况，就必须还清债务，祝您好运

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

1 个答案: