你的BDD规范应该与UI测试分离吗？

Question

昨天我去参加了由Gojko Adzic主讲的关于BDD的精彩演讲。也许我错过了他所说的一两件事情，因此这里有一个问题，希望能为我澄清一些事情。

通常当你在网上看到BDD示例时，它们会在UI中包含步骤。在gherkin语言中，你经常会看到类似这样的东西:

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测试（也可以使用Gherkin语言编写）。

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 / 回归测试分开。

- Tomas Jansson

---

既然你提到了Gojko Adzic，让我引用他的书《Specification by Example》中的一句话： “不要陷入用户界面细节的泥淖中。用户界面是可视化的，所以容易思考。我见过一些项目团队和客户花费数小时描述导航菜单链接的情况。但是该用户界面部分几乎没有风险，那些时间本可以用来讨论更重要的功能。” - Vagif Abilov

与其纠结于用户界面的细节，思考用户在网站上的旅程更为实用。在协作规定时，按照对业务的重要性投入相应的时间来规定规范的部分。那些重要且有风险的项目应该详细探讨。而那些不太重要的项目可能不需要如此精确地规定。 - Vagif Abilov

总结一下：BDD规范不需要用UI术语来表达。此外，UI测试更常见的是端到端测试，这与功能规范不同。 - Vagif Abilov

@Vagif Abilov：你应该把它写成一个答案，我很高兴昨天收到了这本书...但是我昨晚没有时间完成它 :) - Tomas Jansson

Answer 1

BDD的核心在于QA和其他非技术人员与开发人员合作，使用本地语言作为功能定义，从这个角度来看，你提供的两个例子都可能被利益相关者理解为一个特性。但是一般来说，故事越抽象越好。不同之处或潜在问题并不在于提及UI，而在于对布局的假设和讨论。应用程序的初始工作流程可能会改变，因此特性定义的更改可能需要与利益相关者进行新的讨论。如果目标保持不变，则可能不需要进行这些讨论。

话虽如此，实用性很快就会发挥作用。模糊的特性定义将需要更精确的ui定义，这反过来又转化为使用其他UI测试工具编写的步骤定义或测试。编写特性文件的实际步骤定义是最困难的部分，因此一旦您拥有全面的步骤定义集，编写新场景就相当快速。不重用这些UI测试似乎是一种浪费，因此我们将其用于UI测试。

我们仅在某种意义上将UI测试分开，即并非所有场景都与利益相关者讨论。最重要的场景被标记，每个特性都有一个或两个被标记的场景，其余的是UI测试。此外，有时特性文件不是由编写步骤定义的人编写的，因此这使得UI测试编写人员对使用的框架中如何实现UI操作的具体细节了解较少。

- Tatu Lahtela

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

- Andy Waite

---

但是非技术利益相关者关心您点击哪个链接或按钮吗？利益相关者关心的是领域。他们关心建立订单、下订单并收到订单款项。 - Tomas Jansson

这正是我试图说明的 - 这是步骤定义。只有它的名称“Given I place an order for X”出现在特性文件中，因此您的利益相关者不会看到实现细节。 - Andy Waite

为什么不建议将领域测试和UI测试分开？ - Tomas Jansson

就Cucumber功能而言，我的意思是。换句话说，如果没有业务利益相关者会阅读的内容，使用Cucumber就毫无意义，因为这只会增加不必要的开销。然而，除了Cucumber之外，拥有其他类型的测试是可以的，例如针对视图或JavaScript的测试，但您应该使用RSpec、QUnit等来编写它们。 - Andy Waite

关心视觉外观的利益相关者怎么办？我倾向于通过线框图来补充BDD场景以进一步定义视觉效果，但无论如何这都是一个现实的问题。 - Brenden