“情景”对黄瓜“情景大纲”的好处是什么？-Java 学习之路

我知道 scenario 和 scenario outline 之间的差异来自here .

Scenario states the general point of test in more abstract way. Meanwhile, the scenario outline facilitates performing scenario with several examples.

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

功能：功能的 Headers 我想将此模板用于我的功能文件

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  |

但它对我来说没那么有意义 . 我认为场景概述更容易理解，因此没有必要用场景表达测试的一般观点 .

你是否同意我的观点？

我的意思是， what does the scenario do, which scenario outline cannot do?

我建议更简单一点

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  |

我知道它会导致错误，但我认为如果黄瓜团队完全删除场景的概念会更好，而是更多地支持场景概述 .

4 回答

3

这不是关于一个人可以做什么而是另一个关系，而是关于使场景尽可能简单易懂 .

如果只有一个示例，简化它并且不使用示例表，则可以更容易阅读和理解

回复于 2024-04-29T07:27:43+08:00
0
场景优于场景的好处 .
- 无需拥有示例部分 . 如果使用outline，即使您没有使用任何参数，也必须使用带有表的示例部分 .
- 某些场景我需要将整个表作为输入传递 . 使用轮廓时，将整个表作为输入并不容易 .
- 无需定义参数名称并在表中保留相同的参数及其值 .
- 为一个故事和输出表定义输入表有点困难，耗时且令人困惑 .
回复于 2024-04-29T07:27:43+08:00
0
你错了 .

你正在做的是遵循反模式，使你的步骤定义更简洁 . 这样做你就是

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
```
不使用示例表的其他原因是
- 步骤定义要难得多 .
- 步骤定义更难以重用
- 表格中的示例值容易出错，如果我将24更改为23，则会修复拼写错误或更改基本业务规则
- 示例值几乎总是在代码库中重复值
- 示例值需要在代码库更改时进行更新
让我们快速浏览5 .

假设我们有一个弱密码'12345'和一个强密码re432uee8l .

如果我们使用示例表，我们最终会在表中使用硬编码密码，例如
```
registered | re432uee8l | logged in
```
现在，如果我们更改业务规则以说我们的强密码必须包含符号，我们必须更改我们的功能集中的每个强密码示例 .

从一开始就使用Cucumber我强烈推荐

Implemented scenarios (ones that you should be running after every 'push|build|deploy` should have no examples, and no outlines). If you are running outlines and examples you are running scenarios that have not been completed.
回复于 2024-04-29T07:27:43+08:00
0

给定，何时，然后是可以在场景和场景大纲中使用的步骤 . DataTable的情况也是如此（这也是一个步骤约束）

另一方面，引入了Scenario以事务方式执行这些步骤并将执行一次 . 但是，如果提供了DataTable，则可以使用Java代码相应地处理数据 .

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

其他差异： - 在单次执行中，Scenario仅执行一次，而Scenario outline（对于类似的数据跟踪）可以多次执行，具体取决于作为示例提供的数据 . - 场景大纲提供了一种更清晰的方法来保持功能文件更小，更易读，而不是反复写出类似的场景 .

此外，使用Scenario Outline作为Scenario的替代是没有害处的，因为它只是提供了一个额外的循环功能 .

NOTE: 我们应该保留较少的步骤，因为更多的步骤需要更多的时间来执行测试用例 .

回复于 2024-04-29T07:27:43+08:00

“情景”对黄瓜“情景大纲”的好处是什么？

4 回答

相关问题