我的接受测试示例应该是多么具体

Question

我是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>%"

是足够的特定，还是我应该修改给定子句以表示更具体的示例（以sbe的方式思考），例如引用特定的角色，而不是仅仅是"用户"或引用正在进行的精确"操作"（例如：获取客户列表）？

谢谢托尼

Answer 1

进度栏是Asethetics。

测试美学的唯一真实方法是向人们展示它，看看他们的想法。A/B测试对此真的很好。BDD并不是特别适合美学，因为美学并不是真正的系统行为，而是关于用户的所需行为。。

。

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

如果有一些算法将自己适合进度栏行为的方面与代码更直接绑定。

在那个级别上，您可以将"给定，何时，然后"在评论中放置，这已经足够了。级别的步骤与系统级步骤的重复使用方式并不像，因此使它们成为可重复使用的抽象并不像使其易于更改的重要性。坚持使用J/N/Whanyunit，然后模拟其余的。

Answer 2

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

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

您的示例

我个人不会为了测试进度栏而编写场景，因为业务不应对实施任何使用的组件感兴趣（他们不在乎加载栏，他们只是在乎信息实际上加载）。

我认为这将是单位测试。

Answer 3

是的，您应该更具体。如果您只有一种类型的用户，或者此测试案例适用于每个用户组"用户"，则可能足以满足您的测试。但是，我认为您应该指定必须等待的操作，因为TDD就是要对您的代码感到安全，并且如果您尚未对所有可能导致的操作进行测试，该如何确定它在任何地方都可以正常工作。延迟？