Question

昨天我通过Gojko Adzic进行了关于BDD的精彩演讲。我可能错过了他说过的一两件事，所以这里有一个问题，希望能为我清楚一些事情。

通常，当您在线查看BDD示例时，他们已在UI中包含了步骤。在小黄瓜语言中，您经常可以看到类似的内容：

Scenario: Successful booking
    Given I am on the page ...
    When I enter the following ...

或类似的东西。

我的问题是，这与BDD真的有关吗？不应该将BDD定位到域，然后您将这些测试作为UI或回归测试。我在想的是像这样用gherkin语法描述一些预订系统：

BDD规范：

Scenario: Successful booking
    Given I am an authenticated user
    When I place an order with the following items
        | item  | price ($) |
        | book1 | 5         |
    Then I should expect to pay $5
    And I should get a confirmation mail of my order

请注意，我根本不是在构思UI，我只描述了域的工作方式，并且应该在每次构建时运行此测试。然后你可以进行UI测试（也是小黄瓜）：

Scenario: Successful booking
    Given I am logged in on the site
    And I go to the page for item book1
    And I click add to basket
    Then I should have a basket with 1 item and $5
    When I click checkout
    Then I should get to the checkout page

并且它继续，也许它应该被分成两个或三个场景，但这不是重点。这些测试运行较重，应该只在每晚构建上运行。问题的关键在于：您是否应该将BDD规范与UI /回归测试分开。

Answer 1

BDD归结为QA其他非技术人员与使用本机语言作为功能定义的开发人员之间的协作。因此，从这个角度来看，你的两个例子都可能被利益相关者理解为一个特征。

但总的来说，你可以制作“故事”越抽象越好。差异或潜在问题不是提及UI，而是关于布局的潜在假设和讨论。应用程序的初始工作流程可能会发生变化，因此功能定义的更改可能需要与staeholders进行新的讨论。如果目标保持不变，可能并不需要进行谈判。

尽管如此，实用性将很快发挥作用。模糊的特征定义将需要更精确的ui定义，而这又将转变为步骤定义或使用其他UI测试工具编写的测试。编写功能文件的实际步骤定义是最困难的部分，因此一旦您有一套全面的步骤定义，编写新方案就会非常快。在UI测试中不重用这些似乎是浪费，所以我们使用相同的UI测试集。

我们将UI测试分开，因为并非所有场景都与利益相关者讨论过。标记最重要的标记，每个功能都标记了一个或两个scnearios，其余的是UI测试。此外，有时特征文件不是由编写步骤定义的人编写的，因此这使得UI测试编写者不太了解在使用的框架中如何实现UI操作的具体细节。

Answer 2

不建议尝试分离域测试和UI测试。

使用Cucumber的一大优势是非技术利益相关者可以阅读和理解您的规范（测试）。那些人可能并不太关心用户界面细节。

因此，一个好的方法是简单地将UI内容推送到一个层中，以便在步骤定义中，例如

Given /^I place an order for "([^"]*)"$/ do |item|
  visit catalog_url
  click_link item
  click_button "Add To Basket"
  click_button "Submit Order"
end

您的BDD规范是否应与UI测试分开？

2 个答案: