Gherkin场景应该始终有步吗？

Question

有时在Gherkin中定义场景时,Given和When步骤之间没有明确的区别,即用户没有与系统的主动交互,验证的目的是验证系统在某些情况下应该如何看待.

考虑以下:

Scenario: Show current balance
Given user is on account page
Then user should see his balance

VS

Scenario: Show current balance
When user goes to account page
Then user should see his balance

我不确定我会不会总是使用第二种变体.如果我有多个场景共享上下文"用户在帐户页面上",其中一些有其他用户操作,而其他人没有,那么在我看来,将"用户在帐户页面"中保持为给定步骤应该是有效的即使某些情况可能缺乏"何时".这是一种有效的方法吗？

Answer 1

从形式上和技术上来说,Cucumber/SpecFlow不要求你编写一个When-step或者更确切地说,Given/When/Then只是按照它们在场景中编写的顺序执行.在这方面,你不需要一个步骤.

但是,正如Andy Waite写的那样,When-step显示了系统从"Setup"获取的动作或事件,以进入在Then-step中验证的新状态.在这方面,每个测试都应该出现一个步骤(正如你所写的那样:我们测试的是什么).

留下你的最后评论; 如何验证只是设置(鉴于系统已启动,然后数据库是干净的,作为一个天真的例子).在这种情况下,可以跳过When-step.

因此,一如既往,它归结为可读性和理解力.编写方案是为了使我们对系统行为的思考具体而清晰.使用优化的表单来理解和了解相关行为.

在没有考虑到这一点的情况下,我可能会猜测,一般的建议是始终使用一个使事件或行为非常清晰明确的When-step.在可能的情况下,我会回避隐性行为和隐藏行为.

我希望这有帮助.

Answer 2

一般来说，一个场景由3部分组成：

• 设置（给定）
• 行动（何时）
• 验证（当时）

有时不需要设置（或者它是隐式的）。但我想不出有什么情况不需要采取行动和验证。

Answer 3

同意安迪+马库斯的观点，但我有一些可能有用的评论。

\n\n

\n

1. Gherkin 功能文件应该充当系统行为的活文档。因此，场景应该提供足够的细节来向开发人员和其他项目利益相关者（产品所有者、测试人员等）传达体现该功能的业务规则。

   \n\n

   我认为您的问题可能是由于在阐明场景时没有从头到尾考虑此业务规则而产生的。我不得不问某人一个问题，什么是平衡？因此，我觉得你可能需要一个步骤来至少传达这样一个概念——在用户可以查看他们的余额之前，他们必须拥有一个。

   \n\n

   Scenario: Show current balance\n  Given I have a balance\n   When I go to my account page\n   Then I should see my balance\n

\n

2. 设置系统状态（即任何“给定”步骤）以使您能够清楚地测试系统是否正常工作非常重要 - 否则您将如何确定余额实际上是正确的？您可能希望通过指定一些参数来使其更加明确：

   \n\n

   Scenario: Show current balance\n  Given my balance is \xc2\xa310\n   When I go to my account page\n   Then I should see my balance as \xc2\xa310\n

\n

3. 我不确定您使用的是哪种 BDD 框架，但我使用 Behat，它允许您将多个 Gherkin 步骤映射到步骤定义。IE

   \n\n

   user is on account page\nuser goes to account page\n

   \n\n

   两者都可以映射到将用户导航到页面的步骤定义。系统行为是相同的，区分两者的唯一原因是为了使您的场景更具可读性。

\n

\n