BDD场景应该包含实际的测试数据，还是只需要描述它？

Question

我们已经认识到，在定义典型的CRUD场景时，有两种指定测试数据的选项：

选项1：描述要使用的数据，并让实现定义数据

Scenario: Create a region
    Given I have navigated to the "Create Region" page
      And I have typed in a valid name
      And I have typed in a valid code
    When I click the "Save" button
    Then I should be on the "Regions" page
     And the page should show the created region details

选项2：明确指定要使用的测试数据

Scenario: Create a region
    Given I have navigated to the "Create Region" page
      And I have filled out the form as follows
        | Label | Value  |
        | Name  | Europe |
        | Code  | EUR    |
    When I click the "Save" button
    Then I should be on the "Regions" page
     And the page should show the following fields
        | Name   | Code |
        | Europe | EUR  |

就利弊而言，我们已经确定：

选择方案1很好地涵盖了"有效名称"这样的定义发生变化的情况。如果我们选择了选项2，那么处理起来可能会更困难，因为测试数据在多个位置中。选项1明确描述了此测试数据的重要性，特别是如果场景为"输入无效信用卡号码"之类的情况。它也更抽象和BDD，更关注描述而非实现。

但是，选项1使用了非常具体的步骤，这些步骤很难重复使用。例如，"页面应显示创建的区域详细信息"可能仅适用于该场景。相反，我们可以以一种方式实现选项2中的"页面应显示以下字段"，使其可以被其他场景多次重复使用。

我认为选项2似乎更加友好，因为客户可以通过示例看到正在发生的事情，而不必解释更抽象的术语，例如"有效"。但选项2是否更脆弱呢？重构模型可能意味着破坏这些测试，而如果测试数据在代码中定义，则编译器将帮助我们进行模型更改。

我知道这里没有对错答案，但我想听听人们如何决定使用哪个选项的意见。

谢谢！

- James Morcom

Answer 1

我会说这取决于情况。有时候，一个场景可能需要大量的数据来成功运行。通常，其中大部分数据对我们实际测试的事物并不重要，反而成为干扰我们理解场景的噪音。我开始使用一种我称之为“默认数据模式”的方法，提供可以与特定场景数据合并的默认数据。我在这里写了一篇文章：

• UI Tests – Default Data

希望这能帮到你。

- Cheezy

---

请注意，我的雇主因为所谓的安全风险已经封锁了您的网站。 - onedaywhen

Answer 2

我更喜欢选项2。

对于业务用户来说，输入和输出是立即清晰的。如果选择选项1，我们不知道什么是有效数据，因此您的实现可能是错误的。

在适当的情况下，您甚至可以添加无效数据以使表达更加丰富。

Scenario: Filter for Awesome
    Given I have navigated to the "Show People" page
    And I have the following data
    | Name  | Value  |
    |  John | Awesome|
    |  Bob  | OK     |
    |  Jane | Fail   |
When I click the "Filter" button
Then the list should display    
    | Name   | Value   |
    |  John  | Awesome |

然而，您应该根据域来描述数据，而不是具体的实现。这将允许您在应用程序的不同层次进行测试，例如UI服务等。

- Johnno Nolan

---

关于无效数据（为了平衡），我已经更新了原始帖子，提到了选定测试数据的重要性，特别是当场景说明“无效”数据时，Option 1可能更好地描述了这一点。 - James Morcom

Answer 3

每次我考虑这个问题时，我都会改变我的想法。但是如果你仔细思考一下——测试是为了证明你可以创建一个区域。这个标准两种选项都符合。但我同意，第二个选项的视觉提示和开发友好性可能太好了，放弃起来太困难。至少在像这样的例子中。

- nick

Answer 4

我建议您退后一步，问问自己这些场景想要表达的故事和规则是什么。如果有关于有效或无效区域代码的规则，并且您的利益相关者希望使用BDD来描述这些规则，那么您可以使用有效和无效区域代码的具体示例。如果您想描述在创建区域之后可能发生的情况，那么确切的数据并不那么重要。

您的“创建区域”实际上并不是我们在BDD中使用的典型场景。它可以被描述为“当我创建一个东西时，我就可以看到这个东西”。它本身并没有为用户提供任何有价值的东西，因此它不是一个有用的场景。我们寻找的是向最终用户提供有趣或有价值的内容的场景。用户为什么要创建区域？最终目标是什么？也许是为了让另一个用户将其他对象分配给该区域？

示例映射将故事与规则和示例（其中示例成为场景）链接在一起，详情请参见https://cucumber.io/blog/bdd/example-mapping-introduction/。

- spikemanuk