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，您现在需要重构您的需求......）。

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

编辑：我想总而言之，我所得到的是......你所拥有的是一个伟大的测试＆＃34;，但是一个相当糟糕的＆＃34;要求＆＃34;。坚持下去吧！

Answer 2

是的，当真实场景需要时，Gherkin场景中有多个When / Then周期适合。

SaxonMatt's answer表明场景最好用利益相关者语言编写，而不是用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（例如在上面的示例中创建产品），并且知道您正在稀释场景的集成测试能力。

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

Answer 3

我也会说不。

在我的另一篇文章中，Daniel F发现了这篇精彩的文章。以下是相关部分：

Given-When-Then步骤必须按顺序出现，不能重复。给定可能不会跟随当时或然后，并且当可能不跟随然后。原因很简单：任何单个When-Then对表示个人行为。这使得很容易看出，在上面的测试中，实际上有两种行为包括：（1）从搜索栏搜索，以及（2）执行图像搜索。在Gherkin中，一个场景涵盖了一种行为。因此，应该有两种情况而不是一种情景。每当您想要编写多个When-Then对时，请编写单独的方案。（注意：一些BDD框架可能允许无序步骤，但它仍然是反行为的。）

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

Answer 4

我会说不。

当测试失败时，它应该告诉您系统中发生故障的位置。像你的例子那样的长时间测试往往很脆弱，需要更高级别的维护。

您需要定义测试测试的内容（应该是一件事）阅读测试

可以是表单验证测试。
可能是注册测试。
它可以是用户仪表板测试。

需要一定的时间来调查失败的位置以及代码中的相关位置。

Answer 5

我也会说不。

给定是设置的先决条件。什么是动作（可以是什么都不做） Then表单声明。

如果您需要更多操作，请打破测试。

一旦第一次失败，本地化问题就会变得更有用。

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

5 个答案: