在Gherkin写一个"当时那时候给予时"的测试是否可以接受？

Question

在Gherkin写一个"当时那时候给予时"的测试是否可以接受？一个真实的例子如下AllPlayers.com

Scenario: Successfully register a user
  Given I am on homepage
    And I am not logged into an account
  When I follow "create a new account"
    And I fill in "First Name" with "Bobby"
    And I fill in "Last Name" with "Bricks"
    And I fill in "E-mail" with "bbricks@example.com"
    And I select "Jun" from "Birthday Month"
    And I select "22" from "Birthday Day"
    And I select "1985" form "Birthday Year"
    And I select "Male" from "Gender"
    And I fill in "Password" with "123testing"
    And I fill in "Confirm Password" with "123testing"
    And I solve the captcha math problem
    And I click "Create new account"
  Then I should see "the user dashboard"
    And I should see the Registration Wizard
  When I push "Proceed to next step"
  Then the "First Name" field should contain "Bobby"
    And the "Last Name" field should contain "Bricks".

我知道它使用behat,所以解析它不是问题.我只是想写更好的测试.我可以在第一次写,And the Registration Wizard should be filled out with data但这似乎不够具体......

建议？

Answer 1

它取决于所写功能的目标受众.你在那里得到的小黄瓜很可能不是与利益相关者一起写的(即有人不是技术人员,但对业务和网站有既得利益).BDD实际上是关于需求和期望的对话 - 而Gherkin是一种工具,它提供了一种标准/认可的方式,每个人都应该能够阅读,你可以写出要求和期望; 在某种程度上,它可以作为开发人员的自动化测试,也可以作为测试人员的测试脚本.

试图让我的开发人员脱帽 - 我会说商业利益相关者宁愿阅读,也很容易理解......

Scenario: Should be able to successfully register on website
    Given I am new to the website
    And I want to register for a user account
    When I go to the registration form
    And I complete all the required registration details correctly
    Then I will be registered on the website
    And I will be automatically logged in

您仍然可以在此规范的幕后构建相同的测试 - 但此规范具有更大的读者群,这是一个更容易理解的要求,任何人都应该理解.我不是说你得到的东西没有价值 - 远非如此.这将是一个非常有效的测试.但它非常适合开发人员,并且与UI实现高度耦合(如果您重构/重新设计UI,您现在需要重构您的需求......).

我开始有很多像你的小黄瓜规格 - 我仍然偶尔使用它们.一旦你的测试框架建立了一个小小的小黄瓜是一种非常好的方式来编写数据驱动/可配置的单元测试; 它们对我的开发过程仍有很大的价值.但我确实尝试将更"纯"的规范与我的"开发者"规范分开 - 但文件夹和标签/类别.

编辑:我想总结一下我得到的是......你所拥有的是一个伟大的"测试",但是一个相当糟糕的"要求".坚持下去吧!

Answer 2

是的,当真实场景需要它时,Gherkin场景中不止一个When/ Then周期是合适的.

SaxonMatt的答案表明,场景最好用利益相关者语言编写,而不是用UI操作语言编写,并且这样做通常会缩短场景的长度,但是错过了问题的确切点.让我们看看牛角.

Gherkin专为验收测试而设计:测试利益相关者级别要求已经完全实施的测试,即软件实际为利益相关者提供价值.有时提供价值需要不止一个行动 - 响应周期.请考虑以下情形:

Scenario: Guest buys a product
  # This scenario starts with the user not logged in, which doesn't require a step
  Given there is a product named "Elliptical Juicer"

  When I go to the product page for "Elliptical Juicer"
  And I add the product to my shopping cart
  Then I should see 1 product in my shopping cart

  When I request to check out
  Then I should see the account creation form

  When I create an account
  Then I should see the checkout form with 1 product, "Elliptical Juicer"

  When I check out
  Then I should see the checkout success page with 1 product, "Elliptical Juicer"
  And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer"

(请注意,当我在场景中有多个When/ Then周期时,我喜欢用空行分隔它们,以便它们脱颖而出.)

这种情况最好用多个When/ Then周期编写有几个原因:

• 在用户结账之前,他们应该在购物车中看到一个产品(仅作为网站标题中的数字,因此该步骤未提及产品名称).在场景结束时无法测试此要求.(好吧,测试可以在用户将产品添加到购物车后立即收集信息,并在方案结束时断言预期的数量,但这将是毫无意义的偷偷摸摸和混乱.)相反,在自然时断言正确的计数只要用户可以看到,就会在场景中放置.

  类似地,Then I should see the account creation form并且Then I should see the checkout form with 1 product, "Elliptical Juicer"可以测试在自然地测试它们的场景中的点的重要要求.

• 假设我们不关心用户在此过程中看到了什么,只关注他们是否在途中使用他们的产品到达场景的末尾.然后我们可以省略中间Then步骤:

  Given there is a product named "Elliptical Juicer"
  When I go to the product page for "Elliptical Juicer"
  And I add the product to my shopping cart
  And I request to check out
  And I create an account
  And I check out
  Then I should see the checkout success page with 1 product, "Elliptical Juicer"
  And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer"
  

  And I create an account出乎意料的是,不是吗？它要求读者在结账时要求访客用户创建帐户.更明确地说,就像在我给出的场景的第一个版本中一样.

• 假设上述问题都没有让我们信服,我们为整个场景中的每个点编写了一个单独的Gherkin场景,我们需要断言满足要求:

  Scenario: Guest adds a product to their shopping cart
    Given there is a product named "Elliptical Juicer"
    When I go to the product page for "Elliptical Juicer"
    And I add the product to my shopping cart
    Then I should see 1 product in my shopping cart
  
  Scenario: Guest with a product in their shopping cart attempts to check out
    Given I have a product in my shopping cart
    When I request to check out
    Then I should see the account creation form
  
  Scenario: Guest creates an account
    Given I have a product named "Elliptical Juicer" in my shopping cart
    And I am on the account creation form
    When I create an account
    Then I should see the checkout form with 1 product, "Elliptical Juicer"
  
  Scenario: Newly registered user checks out
    Given I am a user
    And I have a product named "Elliptical Juicer" in my shopping cart
    And I am on the checkout form
    When I check out
    Then I should see the checkout success page with 1 product, "Elliptical Juicer"
    And I should receive a checkout confirmation email with 1 product, "Elliptical Juicer"
  

  那是糟糕的!首先,没有一个场景是利益相关者会想到的场景.其次,当其中一个中间状态发生变化时,必须改变两个步骤:断言中间状态的Given步骤和为下一个场景设置中间状态的步骤.这些Given步骤中的每一步都是设置错误状态的机会,即产生集成错误.与单一场景相比,这组场景作为集成测试套件的价值要小得多.您可能几乎已经编写了一系列单元测试.

确实,端到端地编写每个场景可能会导致一些重复.正如您在单元测试中容忍重复比在常规代码中更多,在Gherkin场景中比在单元测试中更容忍重复.不要在可理解性上妥协.分解场景并Given仅在关键点使用s(例如在上面的示例中创建产品),并且知道您正在稀释场景的集成测试能力.

另外,请记住,验收测试应该只是自动测试套件的一部分.仅编写足够的验收测试以涵盖关键场景,并通过单元测试覆盖详细信息.通常,验收测试之间的重复解决方案是用单元测试替换一个.

Answer 3

我也要说不

在我的另一篇文章中，Daniel F发现了这篇很棒的文章。这是相关的部分：

时给定步骤必须按顺序出现，并且不能重复。给定值可能不遵循“当”或“然后”，而“时间”可能不遵循“当”。原因很简单：任何一对“当-那么”对都表示一个单独的行为。这使我们很容易看到在上面的测试中实际上涵盖了两种行为：（1）从搜索栏进行搜索，以及（2）执行图像搜索。在小黄瓜中，一种情况涵盖一种行为。因此，应该有两种情况而不是一种情况。任何时候只要要编写多个“当-然后”对，都可以编写单独的方案。（注意：某些BDD框架可能允许无序的步骤，但仍然会反行为。）

https://automationpanda.com/2017/01/30/bdd-101-writing-good-gherkin/