您的 BDD 规范是否应该与 UI 测试分开？
昨天，我参加了 Gojko Adzic 关于 BDD 的精彩演讲。我可能错过了他说的一两件事，所以这里有一个问题希望能为我澄清一些事情。
通常，当您在网上看到 BDD 示例时，它们会在 UI 中包含步骤。在小黄瓜语言中，您经常可以看到类似的内容：
Scenario: Successful booking
Given I am on the page ...
When I enter the following ...
或者类似的内容。
我的问题是，这真的与 BDD 有关吗？ BDD 不应该针对领域，然后进行 UI 或回归测试等测试。我正在考虑的是这样的使用小黄瓜语法来描述某种预订系统：
BDD Spec：
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/回归测试分开。
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.
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 ...
Or something like that.
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 Spec:
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
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
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
BDD 归结为 QA 其他非技术人员与使用本机语言作为功能定义的开发人员之间的协作。因此，从这个角度来看，您的两个示例都可能被利益相关者理解为一个功能。
但总的来说，“故事”越抽象越好。差异或潜在问题并不在于提及 UI，而是关于布局的潜在假设和讨论。应用程序的初始工作流程可能会发生变化，因此功能定义的更改可能需要与利益相关者进行新的讨论。如果目标保持不变，可能实际上并不需要进行会谈。
也就是说，实用性很快就会发挥作用。不明确的功能定义将需要对 UI 进行更准确的定义，而这又会转化为步骤定义或使用其他 UI 测试工具编写的测试。为功能文件编写实际的步骤定义是最困难的部分，因此一旦您拥有一套全面的步骤定义，编写新场景就会相当快。在 UI 测试中不重用这些似乎是一种浪费，因此我们在 UI 测试中使用相同的集合。
我们分离 UI 测试只是因为并非所有场景都与利益相关者进行讨论。最重要的标记，每个功能都标记一两个场景，其余的是 UI 测试。此外，有时功能文件不是由编写步骤定义的人编写的，因此这使得 UI 测试编写者不太了解 UI 操作在所使用的框架中如何实现的细节。
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.
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.
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.
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.
不建议尝试将域测试和 UI 测试分开。
使用 Cucumber 的一大优势是非技术利益相关者可以阅读和理解您的规范（测试）。这些人可能不太关心用户界面细节。
因此，一个好的方法是简单地将 UI 内容向下推一层到步骤定义内，例如
Trying to separate out domain and UI tests is not recommended.
The big advantage of using Cucumber is that your specs (tests) can be read and understood by non-technical stakeholders. Those people probably aren't too concerned about user interface details.
So a good approach is to simply push the UI stuff down a layer to within the step definitions, e.g.