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，在几个地方测试数据的选项2，这可能会更加困难。选项1明确描述了该测试的数据重要的内容，尤其是在我们说“已输入无效的信用卡号”之类的情况下。它还“感觉到”更抽象和BDD，以某种方式更关心描述而不是实施。

但是，选项1使用非常具体的步骤，很难重复使用。例如，“页面应显示创建的区域详细信息”可能只有此情况只能使用。相反，我们可以以其他情况可以多次重复使用的方式来实现选项2的“该页面应显示以下字段”。

我还认为选项2似乎更友好，因为他们可以看到正在发生的事情，而不必解释更抽象的术语，例如“有效”。选项2会更脆吗？重构模型可能意味着打破这些测试，而如果在代码中定义了测试数据，则编译器将帮助我们进行模型更改。

我感谢这里不会有正确或错误的答案，但想听到人们对他们如何决定使用哪种方式的意见。

谢谢！

Answer 1

我会说这取决于。有时候，场景可能需要大量数据才能完成成功运行。通常，大多数数据对我们实际测试的事情并不重要，因此使噪音从我们试图实现的情况下分散注意力。我开始使用我称之为默认数据模式的东西，以提供可以与方案特定数据合并的默认数据。我在这里写了有关它的文章：

http://www.cheezyworld.com/2010/11/21/ui-tests-default-dat/

我希望这有帮助。

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服务等。

Answer 3

每当我考虑这个问题时，我都会改变主意。但是，如果您考虑一下 - 测试是证明您可以创建一个区域。两个选项都符合的标准。但是我同意，具有选项2和开发人员友善的视觉提示可能太好了，无法拒绝。至少在这样的示例中。