Gherkin 场景概述或多个场景?

Gherkin scenario outlines or multiple scenarios?

在为 BDD 定义 Gherkin 格式的验收标准时是否有首选方法?

我是否应该将场景拆分如下...

Scenario: User saves contact details
Given I am on the contact details page
When I enter the following details
| email          | phone     |
| pete@gmail.com | 012345678 |
And I save the details
Then the details are correctly saved

Scenario: User saves contact details with a very long email address
Given I am on the contact details page
When I enter the following details
| email                                                         | phone     |
| peterpeterperterlongemailaddress1234567890@gmailsomething.com | 012345678 |
And I save the details
Then the details are correctly saved

Scenario: User saves contact details with a very long phone number

etc

或者我应该使用具有多个轮廓的单个场景?

Scenario: User saves contact details
Given I am on the contact details page
When I enter the following details
| email   | phone   |
| <email> | <phone> |
And I save the details
Then the details are correctly saved

Examples: 
| email                                                         | phone                 |
| pete@gmail.com                                                | 012345678             |
| peterpeterperterlongemailaddress1234567890@gmailsomething.com | 012345678             |
| pete@gmail.com                                                | 012345678901234567890 |

后者可能更容易 adapt/add 但对我来说失去了场景的基本概念。

更新 我刚刚看到以下文章,其中讨论了这一点。建议后者是更好的方法。 https://www.hindsightsoftware.com/blog/scenario-outlines

它建议如下:

Scenario: User saves contact details
Given I am on the contact details page
When I enter the following details
| email   | phone   |
| <email> | <phone> |
And I save the details
Then the details are correctly saved

Examples: 
| scenario                  | email                                                         | phone                 |
| basic details saved       | pete@gmail.com                                                | 012345678             |
| very long email address   | peterpeterperterlongemailaddress1234567890@gmailsomething.com | 012345678             |
| very long phone number    | pete@gmail.com                                                | 012345678901234567890 |

作为一般实践,如果您改变输入,但期望得到相同的输出,那么您就有了一个很好的场景大纲。

您可以参数化 Then 步骤,但我反对这样做,因为更改测试断言意味着您已经从根本上更改了测试。这是一个哲学和代码维护问题。

考虑 phone 号码的最大长度,根据您的示例,它应该是 11 个字符。如果最多 11 个字符,并且您有一个测试该边界两侧的场景大纲,那么该场景有多种失败原因。首先,当 11 不再是最大长度时,此外,如果 12 现在是最大长度,该测试也会失败。

有多种失败原因的测试是"flaky"

下面的场景概述改变了断言和输入,这意味着此测试有多种失败原因。

Scenario Outline: User saves contact details
    Given I am on the contact details page
    When I enter the following details
        | email          | phone   |
        | pete@gmail.com | <Phone> |
    And I save the details
    Then the details <Assertion> correctly saved

Examples:
    | Phone                  | Assertion |
    | 012345678901234567890  | Are       |
    | 0123456789012345678901 | Are Not   |

我什至建议将电子邮件方案与 phone 号码方案分开。

每个测试应该只有一个失败的原因。

下面的两个场景看起来像是彼此的重复,但保持大部分输入一致,并且只改变其中一个输入可以让您进行更稳定的测试,但失败的原因很明显:

Scenario Outline: User saves contact phone number
    Given I am on the contact details page
    When I enter the following details
        | email          | phone   |
        | pete@gmail.com | <Phone> |
    And I save the details
    Then the details are correctly saved

Examples:
    | Phone                 |
    | 012345678             |
    | 012345678901234567890 |

Scenario Outline: User saves contact e-mail address
    Given I am on the contact details page
    When I enter the following details
        | email   | phone     |
        | <Email> | 012345678 |
    And I save the details
    Then the details are correctly saved

Examples:
    | Email                                                         |
    | pete@gmail.com                                                |
    | peterpeterperterlongemailaddress1234567890@gmailsomething.com |

现在,当场景失败时,场景名称会提示您应用程序的哪一部分可能是问题所在,这有助于调试。