23

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

我很欣赏这里不会有正确或错误的答案，但想听听人们对他们如何决定使用哪个的意见。

谢谢！

4

4 回答 4

11

我会说这取决于。有时场景可能需要大量数据才能成功运行。通常，大部分数据对于我们实际测试的东西并不重要，因此会成为干扰我们试图通过场景实现的理解的噪音。我开始使用我称之为默认数据模式的东西来提供可以与特定于场景的数据合并的默认数据。我在这里写过：

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

我希望这有帮助。

于 2011-01-15T17:31:03.957 回答
4

我更喜欢选项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 服务等。

于 2011-01-12T21:02:34.100 回答
2

每次想到这个，我都会改变主意。但是，如果您考虑一下 - 测试是为了证明您可以创建一个区域。两个选项都满足的标准。但我同意选项 2 的视觉提示和开发人员友好性可能太好了，无法拒绝。至少在这样的例子中。

于 2011-01-13T21:27:20.267 回答
0

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

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

示例映射，其中故事与规则和示例链接（示例成为场景），在https://cucumber.io/blog/bdd/example-mapping-introduction/中进行了描述

于 2021-03-10T08:38:26.150 回答