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

Answer 4

我建议你退后一步，问问你想用这些场景来说明什么故事和规则。如果有关于什么是有效或无效区域代码的规则，并且您的利益相关者想要使用 BDD 来描述那些规则，那么您可以使用有效和无效区域代码的具体示例。如果你想描述一个区域创建后会发生什么，那么确切的数据就没那么有趣了。

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

示例映射，其中故事与规则和示例相关联（示例变成场景），在 https://cucumber.io/blog/bdd/example-mapping-introduction/

中进行了描述

BDD场景应该包含实际测试数据，还是只描述一下？

4 个答案: