Gherkin：一个场景应该有多少先决条件？
Gherkin: How many preconditions should a scenario have?
我是 Gherkin 和 BDD 的新手。
我们正在使用 Squish 进行 BDD 回归测试。
我们的应用程序非常复杂 - 类似于飞行模拟器。
现在我问自己如何用 Gherkin 编写测试。
由于我们有大量变量作为特定情况的先决条件，我通常会放很多
Given some precondition
And some other precondition
进入我的测试。
我的自然感觉是我应该避免这种情况，因为它会使事情不必要地变得复杂。
是否有关于应该有多少先决条件的经验法则？
我应该尝试将它减少到只有一个吗？
Gherkin 是 Cucumber 能理解的语言。它是一种业务可读的领域特定语言，可让您描述软件的行为，而无需详细说明该行为的实现方式 More here
从上面的说法我的理解是。您不需要每次都添加前提条件，因为使用场景的人知道如何编写和理解 Gherkin 语言。
示例如下：
When I take login as system admin
And I click on new user
And I enter new user details
Then new user is created successful
这里就不用说我在哪里了，其他前提条件比如URL开不开？
第一个前提条件是URL打开与否。
Given I opened URL "http://www.whosebug.com"
And I enter system admin details
And I click on new user
When I enter new user details
Then new user is created successfully
第二个条件新用户详细信息表单具有所有必填字段。这可以是单独的场景。
目标是告诉业务和团队我们正在测试这种情况。它不是测试用例。您无需为测试目的创建大量文档。
与 YAML 或 Python 一样，Gherkin 是一种使用缩进定义结构的 line-oriented 语言。行结束终止语句（称为步骤），空格或制表符可用于缩进。最后，Gherkin 中的大多数行都以一个特殊的关键字开头：
样本
Feature: Some terse yet descriptive text of what is desired
In order to realize a named business value
As an explicit system actor
I want to gain some beneficial outcome which furthers the goal
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too
Scenario: A different situation
...
解析器将输入分为特征、场景和步骤。让我们来看看上面的例子：
Feature: Some terse yet descriptive text of what is desired 启动功能并为其命名。
Scenario: Some determinable business situation 启动场景，并包含场景描述。
接下来的 7 行是场景步骤，每个步骤都与别处定义的正则表达式匹配。
Scenario: A different situation开始下一个场景，依此类推
When you’re executing the feature, the trailing portion of each step (after keywords like Given, And, When, etc) is matched to a regular expression
另请注意，如果您有像我的@Boston 提到的 Given I opened URL "http://www.whosebug.com" 这样的先决条件。推荐使用Background.
例子
Feature: This is test feature
Background: background scenario
Given I opened URL "http://www.whosebug.com"
Scenario: access first senario
Given: I should see this
...
Scenario: access second scenario
Given: I should see that
...
background 将在每个 scenario 之前执行。
当您编写场景时，您可以让步骤背后的代码执行您需要的任何操作，将应用程序设置为测试所需的状态。有一篇很好的文章解释了这一点 here。
我发现如果您可以在步骤中更具描述性，那么当您需要返回以参考它们时，您的测试将更有意义。如果你的步骤只是 Given, click, click, click, Then .. 你很容易忘记测试的重点。您的测试应该是关于系统行为而不是使用系统的分步说明。
就先决条件而言。您需要尽一切努力使应用程序处于您希望测试的状态。
一般规则是尽可能少，同时仍然使测试有用。有多少取决于您的场景的受众。
如果您将小黄瓜场景用于实际的 BDD（行为驱动开发），那么您必须以利益相关者能够理解的方式编写场景。如果这意味着您必须编写许多 Given、And、And 步骤，那么这就是必须的方式。如果这意味着您可以将这些步骤中的几个放在一个更通用的设置步骤中，那就更好了。
如果您仅将 Gherkin 场景用作自动化测试的一种方式，那么请为您的开发团队做任何有益的事情。关于尽可能少的步骤的规则来自于试图确保每个人，无论是技术人员还是非技术人员都理解场景的含义（即它们尽可能清晰和简洁。如果只有技术团队需要理解它然后如上所述你可以使用很多步骤，如果这是你的团队理解它所必需的，或者你可以使用包含更多代码的更少步骤。
对于您有一个非常复杂的系统以进入正确的测试状态的情况，我不会担心可能会设置步骤，只要您最终得到的场景清晰且简短尽可能。如果没有看代码就没有人真正理解的更小更简洁的场景没有任何意义！
Gherkin 是一种业务可读的领域特定语言，专为行为描述而创建。
Gherkin 有两个用途：作为项目的文档和自动化测试。 Gherkin 的语法在作为 Cucumber 代码库一部分的 Treetop 语法中定义。
为了更好地理解 Gherkin，请看下面提到的简单场景：
Feature: As a existing facebook user, I am able to post a birthday greeting on any other existing user's facebook page
Scenario: Verify that Joe Joseph can post a birthday greeting on Sam Joseph's facebook page
Given Joe Joseph is an existing facebook user
Given Sam Joseph is an existing facebook user
Given Joe Joseph is on login page of facebook
Given Joe Joseph logs into his facebook account
When Joe Joseph opens Sam Joseph's facebook page
And Joe Joseph writes "Happy Birthday Sam" on Sam Joseph's facebook page
And Joe Joseph clicks on Post button
Then Joe Joseph verifies that "Happy Birthday Sam" is successfully posted on Sam Joseph's facebook page
在上面的场景中，所有以"Given"开头的语句都是我的前置条件。
因此，就前提条件而言，您可以使用测试所需的尽可能多的前提条件。
我是 Gherkin 和 BDD 的新手。 我们正在使用 Squish 进行 BDD 回归测试。 我们的应用程序非常复杂 - 类似于飞行模拟器。
现在我问自己如何用 Gherkin 编写测试。 由于我们有大量变量作为特定情况的先决条件，我通常会放很多
Given some precondition
And some other precondition
进入我的测试。
我的自然感觉是我应该避免这种情况，因为它会使事情不必要地变得复杂。
是否有关于应该有多少先决条件的经验法则？ 我应该尝试将它减少到只有一个吗？
Gherkin 是 Cucumber 能理解的语言。它是一种业务可读的领域特定语言，可让您描述软件的行为，而无需详细说明该行为的实现方式 More here
从上面的说法我的理解是。您不需要每次都添加前提条件，因为使用场景的人知道如何编写和理解 Gherkin 语言。
示例如下：
When I take login as system admin
And I click on new user
And I enter new user details
Then new user is created successful
这里就不用说我在哪里了，其他前提条件比如URL开不开？
第一个前提条件是URL打开与否。
Given I opened URL "http://www.whosebug.com"
And I enter system admin details
And I click on new user
When I enter new user details
Then new user is created successfully
第二个条件新用户详细信息表单具有所有必填字段。这可以是单独的场景。
目标是告诉业务和团队我们正在测试这种情况。它不是测试用例。您无需为测试目的创建大量文档。
与 YAML 或 Python 一样，Gherkin 是一种使用缩进定义结构的 line-oriented 语言。行结束终止语句（称为步骤），空格或制表符可用于缩进。最后，Gherkin 中的大多数行都以一个特殊的关键字开头：
样本
Feature: Some terse yet descriptive text of what is desired
In order to realize a named business value
As an explicit system actor
I want to gain some beneficial outcome which furthers the goal
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too
Scenario: A different situation
...
解析器将输入分为特征、场景和步骤。让我们来看看上面的例子：
Feature: Some terse yet descriptive text of what is desired启动功能并为其命名。Scenario: Some determinable business situation启动场景，并包含场景描述。接下来的 7 行是场景步骤，每个步骤都与别处定义的正则表达式匹配。
Scenario: A different situation开始下一个场景，依此类推
When you’re executing the feature, the trailing portion of each step (after keywords like Given, And, When, etc) is matched to a regular expression
另请注意，如果您有像我的@Boston 提到的 Given I opened URL "http://www.whosebug.com" 这样的先决条件。推荐使用Background.
例子
Feature: This is test feature
Background: background scenario
Given I opened URL "http://www.whosebug.com"
Scenario: access first senario
Given: I should see this
...
Scenario: access second scenario
Given: I should see that
...
background 将在每个 scenario 之前执行。
当您编写场景时，您可以让步骤背后的代码执行您需要的任何操作，将应用程序设置为测试所需的状态。有一篇很好的文章解释了这一点 here。
我发现如果您可以在步骤中更具描述性，那么当您需要返回以参考它们时，您的测试将更有意义。如果你的步骤只是 Given, click, click, click, Then .. 你很容易忘记测试的重点。您的测试应该是关于系统行为而不是使用系统的分步说明。
就先决条件而言。您需要尽一切努力使应用程序处于您希望测试的状态。
一般规则是尽可能少，同时仍然使测试有用。有多少取决于您的场景的受众。
如果您将小黄瓜场景用于实际的 BDD（行为驱动开发），那么您必须以利益相关者能够理解的方式编写场景。如果这意味着您必须编写许多 Given、And、And 步骤，那么这就是必须的方式。如果这意味着您可以将这些步骤中的几个放在一个更通用的设置步骤中，那就更好了。
如果您仅将 Gherkin 场景用作自动化测试的一种方式，那么请为您的开发团队做任何有益的事情。关于尽可能少的步骤的规则来自于试图确保每个人，无论是技术人员还是非技术人员都理解场景的含义（即它们尽可能清晰和简洁。如果只有技术团队需要理解它然后如上所述你可以使用很多步骤，如果这是你的团队理解它所必需的，或者你可以使用包含更多代码的更少步骤。
对于您有一个非常复杂的系统以进入正确的测试状态的情况，我不会担心可能会设置步骤，只要您最终得到的场景清晰且简短尽可能。如果没有看代码就没有人真正理解的更小更简洁的场景没有任何意义！
Gherkin 是一种业务可读的领域特定语言，专为行为描述而创建。 Gherkin 有两个用途：作为项目的文档和自动化测试。 Gherkin 的语法在作为 Cucumber 代码库一部分的 Treetop 语法中定义。
为了更好地理解 Gherkin，请看下面提到的简单场景：
Feature: As a existing facebook user, I am able to post a birthday greeting on any other existing user's facebook page
Scenario: Verify that Joe Joseph can post a birthday greeting on Sam Joseph's facebook page
Given Joe Joseph is an existing facebook user
Given Sam Joseph is an existing facebook user
Given Joe Joseph is on login page of facebook
Given Joe Joseph logs into his facebook account
When Joe Joseph opens Sam Joseph's facebook page
And Joe Joseph writes "Happy Birthday Sam" on Sam Joseph's facebook page
And Joe Joseph clicks on Post button
Then Joe Joseph verifies that "Happy Birthday Sam" is successfully posted on Sam Joseph's facebook page
在上面的场景中，所有以"Given"开头的语句都是我的前置条件。 因此，就前提条件而言，您可以使用测试所需的尽可能多的前提条件。