关于Cucumber ：小Cucumber 场景大纲还是多重场景？

Gherkin scenario outlines or multiple scenarios?

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Scenario: User saves contact details
Given I am on the contact details page
When I enter the following details
| email | phone |
| [email protected] | 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 |
| [email protected] | 012345678 |
And I save the details
Then the details are correctly saved

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

etc

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

1
2
3
4
5
6
7
8
9
10
11
12
13

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

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

建议如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

一般来说，如果你改变了输入，但期望得到相同的输出，那么你就有一个很好的场景大纲。

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

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

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