cucumber - 小黄瓜场景大纲或多个场景？

Question

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

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

Scenario: User saves contact details
Given I am on the contact details page
When I enter the following details
| email          | phone     |
| [e-mail] | 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     |
| [e-mail] | 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                 |
| [e-mail]                                                | 012345678             |
| [e-mail] | 012345678             |
| [e-mail]                                                | 012345678901234567890 |

后者可能更容易适应/添加，但对我来说失去了场景的基本概念。

更新 我刚刚看到以下文章，其中讨论了这一点。建议后者是更好的方法。 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       | [e-mail]                                                | 012345678             |
| very long email address   | [e-mail] | 012345678             |
| very long phone number    | [e-mail]                                                | 012345678901234567890 |

标签： cucumberbddspecflowgherkin

Answer 1

作为一般实践问题，如果您改变输入，但期望相同的输出，那么您有一个很好的场景大纲案例。

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

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

有多种失败原因的测试是“不稳定的”

下面的场景大纲会改变断言和输入，这意味着该测试有多种失败的原因。

Scenario Outline: User saves contact details
    Given I am on the contact details page
    When I enter the following details
        | email          | phone   |
        | [e-mail] | <Phone> |
    And I save the details
    Then the details <Assertion> correctly saved

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

我什至建议将电子邮件场景与电话号码场景分开。

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

下面的两种情况似乎是彼此重复的，但是保持大部分输入一致，并且只改变其中一个输入可以为您提供更稳定的测试，但由于明显的原因而失败：

Scenario Outline: User saves contact phone number
    Given I am on the contact details page
    When I enter the following details
        | email          | phone   |
        | [e-mail] | <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                                                         |
    | [e-mail]                                                |
    | [e-mail] |

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