2

我是 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术语思考），例如通过引用特定角色而不只是“用户”或引用正在进行的确切“操作”（例如：获取客户列表）？

谢谢，托尼

4

3 回答 3

1

进度条是美学。

测试美学的唯一真正方法是将其展示给人们并看看他们的想法。A/B 测试非常适合这个。BDD 并不是特别适合美学，因为美学实际上并不是关于系统的期望行为，而是关于用户期望的行为。

我们仍在学习如何有效地对人员进行编程。在那之前，用人类而不是脚本来测试美学。

如果有一些算法适合进度条的行为，那么可以肯定，这值得测试......但正如其他人所说，这是最好留给类级 BDD 的东西，其中示例更直接地绑定到代码。

在那个级别，您可以将“Given, When, Then”语句放在评论中，这就足够了。类级步骤的重用方式与系统级步骤的重用方式不同，因此将它们变成可重用的抽象并不像让它们易于更改那么重要。坚持使用 J/N/WhateverUnit 并模拟其余部分。

于 2017-02-22T00:09:48.947 回答
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

一切都是为了清晰，通常更多的是关于如何描述与业务相关的系统行为。

你的例子

我个人不会为了测试进度条而编写场景，因为业务不应该对所使用的任何组件的实现感兴趣（他们不关心加载栏，他们只关心实际的信息负载）。

在我看来，这作为一个单元测试会更好。

于 2017-02-21T12:53:54.840 回答
0

是的，你应该更具体。如果您只有一种类型的用户，或者如果此测试用例适用于每个用户组，“用户”对于您的测试可能已经足够了。但是，我认为您应该指定必须等待的操作，因为 TDD 就是要对您的代码感到安全，如果您没有针对所有可能导致延迟？

于 2017-02-21T12:38:13.050 回答