在 BDD 用户故事/验收测试中混合“此时”和“何时”
您如何处理像这样具有长链的用户故事/验收测试，其中“那时”/“何时”混合在一起？是否最好将其分成一个单独的验收测试，其中一个测试对话框是否出现，然后第二个测试对话框显示后的行为？
Feature: Confirmation before removing products from cart
In order to avoid accidentally removing an item from my cart
As a Customer
I want a confirmation dialog to ask me if I'm sure I want to remove an item
Scenario: I want to remove an item from my cart
Given I have added item "xyz" to my cart
When I click "Remove"
Then a confirmation dialog pops up
And it asks "Are you sure you want to remove this from your cart"
When I click "Yes"
Then item "xyz" should be removed from my cart
How do you handle user stories/acceptance tests that have long chains like this one, where the Then/When mingle together? Is it best to split this into a separate acceptance test where one tests that the dialog appears and then the second one tests the behavior after the dialog has been shown?
Feature: Confirmation before removing products from cart
In order to avoid accidentally removing an item from my cart
As a Customer
I want a confirmation dialog to ask me if I'm sure I want to remove an item
Scenario: I want to remove an item from my cart
Given I have added item "xyz" to my cart
When I click "Remove"
Then a confirmation dialog pops up
And it asks "Are you sure you want to remove this from your cart"
When I click "Yes"
Then item "xyz" should be removed from my cart
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你的场景看起来有点长，而且它与图形用户界面密切相关。如果您将其与系统的功能联系起来，会发生什么？
该场景现在描述了对用户有用的内容，并且更容易重构。
我和我一样热爱 BDD，因为我也遇到过类似的情况。我们进行了 120 次验收测试，但大部分都失败了。有人在其中添加了一个与您所描述的非常相似的确认对话框，并立即突破了 80 多个验收测试。通过将它们转变为具有高级可重用步骤的场景，即使我们用于实现系统功能的机制发生变化，我们也可以轻松重构并保持测试正常运行。按钮的实际单击发生在这些可重用步骤中，并且每个步骤可以有多个 UI 操作。
我在这里写了一个场景，如果有用的话可以执行此操作（它是 DSL 而不是英语，但您应该明白这个想法）：
http://code.google.com/p/wipflash/source/browse/Example.PetShop.Scenarios/PetRegistrationAndPurchase.cs
Your scenario seems a little long, and it's quite heavily tied to the gui. What would happen if you tied it to the capabilities of the system instead?
The scenario now describes stuff that's useful to the user, and it's easier to refactor.
I love BDD as much as I do because I had a situation much like this. We had 120 acceptance tests and they were mostly failing. Someone had put a confirmation dialogue box in much like the one you describe, and instantly broke over 80 acceptance tests. By turning them into scenarios with high-level, reusable steps instead, we can easily refactor and keep the tests working even if the mechanisms we use to implement the capabilities of the system change. The actual clicking of buttons happens within those reusable steps, and it's OK to have more than one UI action per step.
I wrote a scenario here which does this if it's useful (it's a DSL rather than English but you should get the idea):
http://code.google.com/p/wipflash/source/browse/Example.PetShop.Scenarios/PetRegistrationAndPurchase.cs
问题实际上是“分支”是什么。
如果有多个步骤，则每个步骤都必须有用户选择。应该有多个“何时”。这应该形成一棵丰富的树，每个分支都有许多用户选择的替代方案。每个可能的结果都应该有它自己的测试，以做出各种选择并得出该结果。
具有两个用户选择的三步序列有 8 条可能的路径。不同的路径可能会达到相同的结果（也可能不会）。但你应该有多种途径。
如果它只是顺序的（因为有人想编写顺序步骤）并且用户没有选择，那么它并不是真正由考虑用户行为驱动的，不是吗？
我没有看到选择。别无选择==难闻的气味。但很容易测试，因为只有一个结果带有一系列强制步骤，用户几乎没有选择或没有选择。
如果你正确地做出选择，那么每个步骤都会有多个结果，并且每个步骤都应该独立测试。
The question is really one of what the "branches" are.
If there are multiple steps there must be user choices at each step. There should be multiple "When"'s. This should form a rich tree with lots of user-selected alternatives at each branch. Each possible outcome should have it's own test to make the various choices and arrive at that outcome.
A three step sequence with two user choices is 8 possible paths. Different paths may arrive at the same outcome (or may not). But you should have multiple paths through this.
If it's just sequential (because someone felt like writing sequential steps) and the user has no choices, then it's not really driven by consideration of the user's behavior, is it?
I don't see the choices. No choices == bad smell. But easy to test since there's only one outcome with a sequence of captive steps where the user has few or no choices.
If you work out the choices properly, then each step has multiple outcomes and each step should be tested independently.