黄瓜中的“场景”比“场景大纲”有什么好处？

Question

我从here 知道 scenario 和 scenario outline 之间的区别。

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比较容易理解，所以没有必要用scenario来表达测试的大致观点。

你同意我的观点吗？

我的意思是，场景做什么，哪个场景大纲不能做什么？

我建议选择更简单的

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  |

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

Answer 1

这不是关于一个人可以做什么，而是关于使场景尽可能简单和易于理解。

如果只有一个例子，把它简化，不要使用例子表，这样更容易阅读和理解

Answer 2

Given, When, Then 是可以在 Scenario 和 Scenario Outline 中使用的步骤。 DataTable 也是如此（这又是一个步骤约束）

一方面，Scenario 被引入以事务方式执行步骤，并且将执行一次。但是，如果提供了 DataTable，您可以使用 Java 代码对数据进行相应的处理。

另一方面，Scenario Outline 为您提供了仅从基于 Gherkin 的功能文件执行循环的灵活性。

其他区别： - 在单次执行中，场景仅执行一次，而场景大纲（对于类似的数据跟踪）可以多次执行，具体取决于作为示例提供的数据。 - 场景大纲提供了一种更简洁的方法来保持功能文件更小且更具可读性，而不是重复编写类似的场景。

此外，使用 Scenario Outline 作为 Scenario 的替代品并没有什么坏处，因为它只是提供了额外的循环功能。

注意：我们应该保留更少的步骤，因为更多的步骤将需要更多的时间来执行测试用例。

Answer 3

情景优于情景。

1. 不需要有示例部分。如果你使用大纲，它是强制性的 使用带有表格的示例部分，即使您不使用 任何参数。
2. 在某些情况下，我需要将整个表作为输入传递。使用大纲时将整个表格作为输入传递并不容易。
3. 无需定义参数名称，并在表中保持相同的参数及其值。
4. 为一个故事定义输入表和输出表有点困难、耗时且令人困惑。

Answer 4

你大错特错了。

您所做的是遵循反模式以使您的步骤定义更加简洁。这样做你就是

1) 显着减少步骤定义传达的信息量

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

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

在 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` 之后运行的场景应该没有示例，也没有大纲）。如果您正在运行大纲和示例，那么您正在运行尚未完成的场景。

Answer 5

如果编码正确，场景大纲会在场景之上有更多好处。 Scenario 和 Scenario Outline 有不同的用途，它们的编写方式相同，但 Scenario Outline 以示例表的形式获取用户数据并运行场景。因此，与其用不同的数据重复相同的场景，不如编写一个场景大纲并将所有数据写入示例表中。可以使代码尽可能通用，以增强步骤定义的重用并遵循编码实践。