cucumber - cucumber 中 "scenario"相对于 "scenario outline"有什么好处？

Question

我知道 here 中的场景和场景大纲之间的区别。

Scenario states 以更抽象的方式测试的一般点。同时，scenario outline通过几个示例来帮助执行场景。

所以，我们通常会写feature file如下。它以 scenario 开头然后完成 scenario outline .

功能:您的功能的标题 我想将此模板用于我的功能文件

 Scenario: Eating
  Given I have "N" cucumbers
  When I eat "K" ones of them
  Then I will have "N-K" ones

Scenario Outline: eating
  Given there are <start> cucumbers
  When I eat <eat> cucumbers
  Then I should have <left> cucumbers

  Examples:
    | start | eat | left |
    |  12   |  5  |  7   |
    |  20   |  5  |  15  |

但这对我来说没有多大意义。我认为场景大纲更容易理解，因此不需要用场景来表达测试的总体观点。

你同意我的观点吗？

我的意思是，该场景可以做什么，哪些场景大纲不能做什么？

我建议选择更简单的

Scenario Outline: eating
  Given there are <start> cucumbers
  When I eat <eat> cucumbers
  Then I should have <left> cucumbers

  Examples:
    | start | eat | left |
    |  12   |  5  |  7   |
    |  20   |  5  |  15  |

我知道这会导致错误，但我认为如果 Cucumber 团队完全删除场景的概念，而是更多地支持场景大纲，那就更好了。

Answer 1

你大错特错了。

您正在做的是遵循反模式以使您的步骤定义更加简洁。这样做时，您是

1) 大幅减少步骤定义传达的信息量

2) 增加运行时间(示例表鼓励运行许多示例。在表中，有两行执行完全相同的操作)

3) 为场景的所有 future 执行创建维护问题。

将示例表与 Cucumber 结合使用的唯一原因是让您更轻松地与利益相关者进行协作。在这里，我们使用大纲和示例来粗略总结您想要在特定领域实现的目标。一旦掌握了这些，您应该提取各个场景来探索和记录每个示例所代表的特定规则和策略。因此，作为实现过程的一部分，您正在将大纲场景改进为质量更高的单个场景

如果我们采用更好的示例表

user           | password  | result
not_registered |  goodpass | user not found
registered     |  badpass  | bad password
registered     | goodpass  | logged in

那么我们最好将其分解为单独的场景，而不是出于多种原因将内容保留在表格中。

首先，我们可以更详细地记录每项政策。如果我们以注册的 badpass 错误密码为例，我们可以得到

Scenario: Login with bad password
  Given I am registered
  When I login with a bad password
  Then I should see a bad password error

现在我们可能会认为显示错误密码错误不是一个好主意，因为它可以通过确认注册帐户存在来帮助人们破解帐户。所以我们也会改进这个场景

Scenario: Login with bad password (show login error only to prevent account identification)
  Given I am registered
  When I login with a bad password
  Then I should see a bad login error

各个场景提供了添加文档和使用不同步骤的机会。更新示例表的通信量要少得多(您必须猜测为什么错误的密码会变成错误的登录)

registered     |  badpass  | bad login

不使用示例表的其他原因是

1. 步骤定义更难编写。
2. 步骤定义更难重用
3. 表中的示例值很容易出错，如果我将 24 更改为 23 是为了修复拼写错误或更改基本业务规则
4. 示例值几乎总是代码库中值的重复
5. 当代码库发生变化时，示例值需要更新

让我们快速浏览一下 5。

假设我们有一个弱密码“12345”和一个强密码 re432uee8l。

如果我们使用示例表，我们最终会在表中得到硬编码的密码，例如

registered | re432uee8l | logged in

现在，如果我们更改业务规则，规定强密码中必须包含符号，则必须更改功能集中的每个强密码示例。

从一开始就使用 Cucumber，我强烈建议

已实现的场景(每次“push|build|deploy”后应该运行的场景应该没有示例，也没有大纲)。如果您正在运行大纲和示例，那么您正在运行尚未完成的场景。