如何处理具有类似长链的用户故事/验收测试,其中Then / When混合在一起?是否最好将其拆分为单独的验收测试,其中一个测试对话框出现,然后第二个测试对话框显示后的行为?
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
答案 0 :(得分:2)
你的情景似乎有点长,而且与gui紧密相关。如果你将它与系统的功能联系起来会发生什么?
Scenario: I want to remove an item from my cart
Given I have a cart containing "xyz"
When I remove "xyz" from my cart
Then my cart should be empty.
该场景现在描述了对用户有用的内容,并且更容易重构。
我和我一样喜欢BDD因为我的情况很像这样。我们有120次验收测试,他们大多都失败了。有人像你描述的那样放了一个确认对话框,并立即打破了80个验收测试。通过将它们转换为具有高级可重用步骤的场景,我们可以轻松地重构并保持测试工作,即使我们用于实现系统功能的机制发生变化。按钮的实际点击发生在这些可重复使用的步骤中,并且每步可以有多个UI操作。
我在这里写了一个场景,如果它有用(这是一个DSL而不是英语,但你应该明白的话),这样做:
答案 1 :(得分:1)
问题实际上是“分支”是什么。
如果有多个步骤,则每个步骤都必须有用户选择。应该有多个“何时”。这应该形成一个丰富的树,每个分支都有许多用户选择的备选方案。每个可能的结果应该有它自己的测试来做出各种选择并达到那个结果。
具有两个用户选择的三步序列是8个可能的路径。不同的路径可能达到相同的结果(或可能不会)。但是你应该有多条路径。
如果它只是顺序的(因为有人觉得要编写顺序步骤)并且用户没有选择,那么它并不是真正考虑用户的行为,是吗?
我没有看到选择。没有选择==难闻的气味。但是很容易测试,因为只有一个结果是一系列强制性步骤,用户很少或没有选择。
如果你正确地做出了选择,那么每个步骤都有多个结果,每个步骤都应该独立测试。