Question

就最佳实践而言，我想知道最好是使用单个方案大纲来产生一个包含多行的Examples部分或多个scenario outline的情况。例如：

由于我讨厌重复的代码，并且我的测试用例共享相同的过程逻辑，因此我设计了具有这种逻辑的单个方案，并为每个测试用例包含一个示例行：

Scenario Outline: My scenario has many rows in the examples section
  When I perform my request with the following inputs: <param1>, <param2>, ..., <param11>    
Examples:
  | one    | one    | one    | one    | one    | one    | one    | one    | one    | one    | one    |
  | two    | two    | two    | two    | two    | two    | two    | two    | two    | two    | two    |
...
  | eleven | eleven | eleven | eleven | eleven | eleven | eleven | eleven | eleven | eleven | eleven |

但是，我发现这种方法的可读性较差，因此我想知道是否最好有多个scenario outlines重复相同的逻辑，例如：

Scenario Outline: My scenario ONE
   When I perform my request with the specific inputs for test case ONE
   ...
Scenario Outline: My scenario TWO
   When I perform my request with the specific inputs for test case TWO
   ...

Scenario Outline: My scenario ELEVEN
   When I perform my request with the specific inputs for test case ELEVEN
   ...

尽管我讨厌重复自己，但我不得不说这种方法更具可读性。

哪种方法是最佳做法？

谢谢您的时间

Answer 1

我建议使用方案大纲。当您必须对方案进行更改（例如在方案中添加或删除步骤）时，这很简洁，并且使工作变得容易。

我对方案大纲方法看到的唯一限制是每个方案的you can't define your own description。但是，我认为您应该可以通过探索runtime options来解决此问题。

Answer 2

我建议完全避免场景概述。编写测试时，清晰度远比DRY重要。

正如supputuri在他的答案中使用方案大纲所指出的那样，您不能为每个示例定义自己的方案。这是一个严重的失败。这意味着您必须根据示例行提供的值来推断描述。如果希望该推断可靠，则必须在示例行中添加额外的字段，这会使行变得更加复杂。如果要使行简单，则必须处理歧义。

每个示例行都应测试对业务特定且有用的事物，如果是这种情况，我们的场景应描述该事物的含义和原因，而不是在一组示例中混淆该事物。

因此，这是否意味着在黄瓜中没有放置示例的位置-完全不是

示例对于启动编写场景的过程非常有用，并且可以在讨论中非常有效地用来说明需求。但是，随着您开始实施并且对功能范围和细节的理解增加，每个示例都需要成熟到特定的场景，并且通过此过程，您将对问题域有更好的了解，从而可以帮助您编写更好的代码。

我多年前写的这篇文章更加详细，http://pages.andrew.premdas.org/2011/06/27/composable-features-and-tables.html

黄瓜：许多示例行与许多方案概述

2 个答案: