我的验收测试示例有多具体?

时间:2017-02-20 21:56:16

标签: bdd acceptance-testing atdd

我是Gherkin / ATDD / BDD的新手。我正在起草以下验收测试:

Given a user is waiting for an operation to complete
    And the operation is <percent>% complete
When <threshold> seconds elapse
Then a progress indicator should be displayed
    And the progress indicator should display "<percent>%"

这个特定的是否足够,或者我应该修改Given子句来表示一个更具体的例子(用SBE术语思考),例如通过引用特定的角色而不仅仅是&# 34;用户&#34;或引用确切的&#34;操作&#34;正在进行中(例如:获取客户名单)?

谢谢, 贝

3 个答案:

答案 0 :(得分:1)

进度条是一种美学。

测试美学的唯一真正方法是向人们展示并看到他们的想法。 A / B测试对此非常有用。 BDD并不特别适合美学,因为美学并不是关于系统的理想行为,而是关于用户的理想行为。

我们仍在学习如何有效地为人们编程。在那之前,用人而不是脚本来测试美学。

如果某些算法适用于进度条行为的一个方面,那么确定,那将值得测试...但正如其他人所说的那样,这是最好留给课堂的东西-level BDD,其中的示例更直接地与代码绑定。

在这个级别,你可以放"Given, When, Then" statements in comments并且它已经足够好了。类级步骤不会像系统级步骤一样重复使用,因此将它们变成可重用的抽象并不像使它们易于更改那么重要。坚持使用J / N / WhateverUnit并嘲笑其余部分。

答案 1 :(得分:0)

是的,你应该更具体。如果您只有一种类型的用户,或者此测试用例适用于每个用户组&#34; user&#34;对你的测试来说可能已经足够了。但是,我认为您应该指定必须等待的操作,因为TDD对您的代码感到安全,如果您还没有对所有操作进行测试,那么如何确保它在任何地方都能正常工作?可能会导致延迟?

答案 2 :(得分:0)

<强> BDD

行为驱动开发完全是关于开发团队和业务之间的对话。其中的要素文件和方案应始终与特定的业务需求,功能或能力相关,这意味着业务和开发团队在所描述的内容之间完全清楚。

举个例子:

Feature: Rewards for frequent flyers
   As a frequent flyer
   I should receive points to my account
   So that I am more likely to book with BDD Airlines again in the future

 Scenario: I get flyer miles
   Given I book a flight 
    And this flight earns 100 miles
   When I land
   Then my account should have 100 miles added to it

问题是,这概述了整个问题还是需要更多信息? 开发团队是否能够使用此对话构建一些内容(正如您对SBE所做的那样)?

这会更好吗?:

Feature: Rewards for frequent flyers
   As a frequent flyer
   I should receive points to my account
   So that I am more likely to book with BDD Airlines again in the future

 Scenario: Passenger gets flyer miles
   Given the account number 12341234 has a ticket for the "LGW-MAN" flight
     And this route earns 100 miles
     And the ticket is scanned at "LGW"
   When the flight lands at "MAN"
   Then the account 12341234 is rewarded 100 miles

 Scenario: Passenger missed their flight
   Given the account number 12341234 has a ticket for the "LGW-MAN" flight
     And this route earns 100 miles
     And the ticket is not scanned at "LGW"
   When the flight lands at "MAN"
   Then the account 12341234 is not rewarded any miles

 Scenario: Passenger gets kicked off the plane
   Given the account number 12341234 has a ticket for the "LGW-MAN" flight
     And this route earns 100 miles
     And the ticket is scanned at "LGW"
     But the ticket is removed from the flight
   When the flight lands at "MAN"
   Then the account 12341234 is not rewarded any miles

这完全取决于清晰度,通常更多的是关于如何描述系统的行为与业务的关系。

您的示例

我个人不会为了测试进度条而编写一个方案,因为业务不应该对所使用的任何组件的实现感兴趣(他们不关心加载吧,他们只关心信息实际加载。)

在我看来,作为单元测试会更好。