Testing BDD规范应该与UI测试分开吗？

昨天我参加了一个关于BDD的精彩演讲。我可能错过了他说的一两句话，所以这里有一个问题，希望能为我澄清一些事情

通常，当您在线看到BDD示例时，它们会在UI中包含步骤。在小黄瓜语言中，您经常可以看到如下内容：

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

或者类似的

我的问题是，这真的与BDD有关系吗？BDD不应该以域为目标，然后你就有了UI或回归测试之类的测试吗。我想的是这样的，使用小黄瓜语法来描述某种预订系统：

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测试（也是小黄瓜）：

---

它还在继续，也许应该分为两到三种情况，但这不是重点。这些类型的测试运行起来比较繁重，可能只能在夜间版本上运行。问题的重点仍然是：您是否应该将BDD规范与UI/回归测试分开。

不建议尝试将域和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归结为QA和其他非技术人员与开发人员之间的协作，开发人员使用本机语言作为功能的定义。因此，从这个角度来看，您的两个示例都可能被涉众理解为一个特性

但总的来说，你能把“故事”写得越抽象越好。区别或潜在问题不在于提及UI，而是关于布局的潜在假设和讨论。应用程序的初始工作流可能会更改，因此功能定义中的更改可能需要与管理员进行新的讨论。如果目标保持不变，可能不需要进行会谈

也就是说，实用性将很快发挥作用。模棱两可的特性定义将需要对ui进行更精确的定义，而这又会转化为步骤定义或使用其他ui测试工具编写的测试。编写要素文件的实际步骤定义是最困难的部分，因此，一旦有了一套全面的步骤定义，编写新方案就相当快了。在UI测试中不重用这些似乎是一种浪费，因此我们对UI测试使用相同的集合

---

我们仅在并非所有场景都与利益相关者讨论的意义上分离UI测试。最重要的功能都已标记，每个功能都有一个或两个标记的scnearios，其余的都是UI测试。此外，有时功能文件不是由编写步骤定义的人员编写的，因此这使得UI测试编写人员对在使用的框架中如何实现UI操作的细节知之甚少。

因为您指的是Gojko Adzic，让我引用他的书《示例规范》：“不要陷入用户界面细节中。用户界面是可视化的，因此很容易思考。我见过一些项目，其中团队和客户花费数小时描述导航菜单链接。但用户界面的这一部分几乎没有风险，而这段时间本可以用来讨论更重要的功能。[…]（引文继续）：“与其停留在用户界面细节上，不如考虑用户在网站上的行程。在协同指定时，根据规范对业务的重要性，在部分规范上投入时间。应详细探讨重要且有风险的项目。那些不那么重要的可能不需要如此精确地指定。总而言之：BDD规范不需要用UI来表示。此外，UI测试更多的是端到端测试，这与功能规范不同。@Vagif Abliov：你应该把它作为一个答案来写，我很高兴我昨天收到了这本书。。。但我昨晚没有时间完成：）但非技术性的利益相关者是否关心您单击的链接或按钮？利益相关者关心这个领域。他们关心建立订单、下订单和获得订单的付款。这正是我想要说明的——这是步骤定义。功能文件中只显示其名称“Given I place a order for X”，因此您的干系人看不到实现细节。为什么不建议将域测试和UI测试分开？我是说在功能方面。换句话说，使用Cucumber进行业务干系人都看不到的事情没有什么意义，因为它只会增加不必要的开销。但是，除了cumber测试之外，还可以进行其他类型的测试，例如视图或JavaScript测试，但是您可以使用RSpec、QUnit等编写测试。那么关心视觉外观的涉众呢？我倾向于用线框来补充BDD场景，以进一步定义视觉效果，但这是一个现实的问题。

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