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会更脆吗？重构模型可能意味着打破这些测试，而如果测试数据是在代码中定义的，编译器将帮助我们进行模型更改。

我很欣赏这里没有正确或错误的答案，但希望听到人们对如何决定使用哪些问题的看法。

谢谢！

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和开发人员友好的视觉提示可能太好了，不能拒绝。在这样的例子中，至少。