设计表单 Cucumber 场景的最佳 BDD 实践
假设您有一个创建新用户的表单。 你如何编写你的 Cucumber 场景？
1.)
Given I am logged in as admin
When I create a new user
Then I should see "Successfully created user"
2.)
Given I am logged in as admin
When I go to Create new user
And I fill in "Name" with "Name111"
And I fill in "Password" with "Password111"
And I press "Create new user"
Then I should see "Successfully created user"
如果您选择 1.) 您在哪里记录用户的要求（用户应该有名称和密码）。我发现 BDD 与行为有关，但在某些时候，您和利益相关者必须指定用户应该具有哪些属性，不是吗？
我对 BDD 很陌生，所以我很感激任何建议......
Lets say you have a form which creates a new user.
How do you write your Cucumber scenario?
1.)
Given I am logged in as admin
When I create a new user
Then I should see "Successfully created user"
2.)
Given I am logged in as admin
When I go to Create new user
And I fill in "Name" with "Name111"
And I fill in "Password" with "Password111"
And I press "Create new user"
Then I should see "Successfully created user"
If you choose 1.) where do you document the requirements for a User (A user should have a name and a password). I see that BDD is about behavior but at some point you and the stakeholder have to specify which properties a user should have, don't you?
I'm very new to BDD so I appreciate any advise...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您应该阅读命令式场景与声明式场景。
——阿斯拉克。黄瓜的创造者。
You should read Imperative vs Declarative Scenarios.
--Aslak. Creator of Cucumber.
你写的场景水平相当低。除非您实际上正在生产要出售的安全登录功能，否则我会坚持使用满意的案例并对其余部分进行单元/手动测试。如果不这样做，您将创建如此多的场景，这将是维护的噩梦。
找出您正在创建的产品与所有类似产品的区别，然后将其作为场景的价值。然后它会看起来像这样：
坚持真正的高级功能，而不是基于低级表单的步骤。例如：
有一个称为“页面范式”的概念，您可以在其中创建一个包含页面或屏幕可以执行的所有低级步骤的类。然后，您可以从较高级别的 Cucumber 步骤装置中调用页面上的这些低级别步骤。
您的企业将更多地参与此类场景。 BDD 的主要目的不是生成自动化测试，而是围绕场景进行对话，以便您可以在麻烦地实现代码之前找出哪里出了问题以及可以考虑哪些其他选项。自动化测试是一个很好的副产品。
对话以及通过对话获得的知识是 BDD 与 ATDD（验收测试驱动开发）的不同之处。这就是为什么我们使用“Example、Scenario、Given、When、Then、Context、Event、Outcome”等语言而不是“Test、SetUp、TearDown、Act、Arrange、Assert”等语言 - 所以我们可以用同一种语言与业务人员、BA 和测试人员讨论这些问题。
请参阅 Dan North 关于 Deliberate Discovery 的文章以及他的其余文章博客了解更多信息，祝 BDD 好运！
The scenarios you've written are fairly low level. Unless you're actually producing secure login functionality to sell, I'd stick to the happy case and unit / manual test the rest. If you don't, you'll create so many scenarios it'll be a maintenance nightmare.
Find out what differentiates the product you're creating from all the similar products, then target that as the value of the scenario. Then it will look like this:
Stick to the really high-level capabilities, rather than low-level form-based steps. For instance:
There's a concept called the "Page Paradigm", in which you create a class with all the low-level steps that the page or screen can perform. You can then call those low-level steps on the page from within the higher-level Cucumber step fixtures.
Your business will be much more engaged with scenarios like this. The main purpose of BDD is not to produce automated tests, but to have conversations around the scenarios so that you can find out where you're going wrong and what other options you could consider before you go to the trouble of implementing the code. Automated tests are a nice by-product.
The conversations, and the learning you get by talking through them, are the things which make BDD different from ATDD (Acceptance Test Driven Development). That's why we use language like Example, Scenario, Given, When, Then, Context, Event, Outcome instead of Test, SetUp, TearDown, Act, Arrange, Assert - so we can talk about these with business, BAs and testers in the same language.
See Dan North's article on Deliberate Discovery and the rest of his blog for more, and good luck with the BDD!
任何一个都会起作用。使用#1，您将创建一个步骤来处理表单的填写。我更喜欢 #1 和 #2 的混合，因为我经常使用场景大纲，例如：
Either one will work. With #1 you would create a step to handel the filling in of the form. I prefer a hybrid of #1 and #2 because I use Scenario Outlines alot for example: