是否应将BDD规范与UI测试分开? [英] Should your BDD specifications be separated from your UI tests?

问题描述

昨天，我去了 Gojko Adzic 上有关BDD的精彩演讲.我可能错过了他说的一两件事，所以这是一个问题，希望可以为我解决一些问题.

Yesterday I went to a great presentation by Gojko Adzic about BDD. I might have missed one or two things he said so here is one question that hopefully will clear somethings up for me.

通常，当您在线上看到BDD示例时，它们在UI中包含步骤.在一种小黄瓜语言中，您经常会看到类似以下内容:

Often when you see BDD example online they have included steps in the UI. In a gherkin language you can often see something like:

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

或者类似的东西.

我的问题是，使用BDD真的可以做到吗?不应将BDD定位于域，然后您需要进行UI或回归测试之类的测试.我在想的是这样的事情，使用小黄瓜语法来描述某种预订系统:

My question is, does that really have with BDD to do? Shouldn't BDD be targeted towards the domain and then you have those kind of tests as UI or regression tests. What I am thinking about is something like this use gherkin syntax to describe somekind of booking system:

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测试(也可以是小黄瓜):

Note that I am not mentoning the UI at all, I am only describing how the domain works and this test should be run on every build. Then you can have your UI test (also 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/回归测试分开吗?

and it continues, maybe it should be separated into two or three scenarios but that is not the point. Theses kind of tests are heavier to run and should probably only be run on nightly builds. The point of the question is still: Should you separated you BDD specs from your UI/regression test.

推荐答案

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

BDD boils down to collaboration between QA other non-technical people with the developers using native language as definitions for the functionality. So from this perspective, both of your examples are likely to be understood as a feature by the stakeholders.

但是通常，您可以使故事"越抽象，越好.差异或潜在的问题并不是要提到UI，而是关于布局的潜在假设和讨论.应用程序的初始工作流程可能会更改，因此功能定义的更改可能需要与利益相关者进行新的讨论.如果目标保持不变，那么实际上可能不需要进行对话.

But in general, the more abstract you can make the "story", the better. The difference,or potential issue, isn't so much about mentioning the UI, but potential assumptions and discussions about the layout. The initial workflow of the application is likely to change, so changes in the feature definition might require new discussions with the staeholders. Talks that might not really be required if the goal remains the same.

也就是说，实用性将很快发挥作用.模糊的功能定义将需要对ui进行更精确的定义，然后将其转变为步骤定义或使用其他UI测试工具编写的测试.为功能文件编写实际的步骤定义是最难的部分，因此，一旦有了一套全面的步骤定义，编写新方案就将很快.不在UI测试中重复使用这些设置似乎是一种浪费，因此我们对UI测试使用相同的集合.

That said, practicality will come into play very quickly. An ambiguous feature definition will require a more exact definition for the ui, and that is in turn turned into a step definition or tests written with other UI testing tools. Writing the actual step definitions for the feature files is the hardest part so writing new scenarios is rather quick once you have a comprehensive set of step definitions in place. Not reusing these in UI tests seems like a waste, so we use the same set for UI tests.

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

We separate the UI tests only in the sense that not all scenarios are discussed with the stakeholdes. The most important ones tagged, and each feature has one or two scnearios tagged and the rest are UI tests. Also, sometimes the feature files are not written by the person writing the step definitions, so this allows the UI test writer to be less knowledgeable about the specifics how the UI operations are implemented in the framework in use.

这篇关于是否应将BDD规范与UI测试分开?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！