我的验收测试示例应该有多具体？答案

【问题标题】：How specific should my acceptance test example be?我的验收测试示例应该有多具体？
【发布时间】：2017-02-20 21:56:15
【问题描述】：

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

谢谢，托尼

【问题讨论】：

标签： bdd acceptance-testing atdd

【解决方案1】：

进度条是美学。

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

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

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

在那个级别，您只需输入"Given, When, Then" statements in comments 就足够了。类级步骤的重用方式与系统级步骤的重用方式不同，因此将它们变成可重用的抽象并不像让它们易于更改那么重要。坚持使用 J/N/WhateverUnit 并模拟其余部分。

【讨论】：

感谢您的洞察力。它是实际上我在这里追求的算法，即在飞行中的异步操作期间经过 x 秒后显示进度指示器。我确实喜欢 GWT cmets 方法，因为语法甚至可以为技术单元测试带来表现力和清晰性。 “[BDD]...这与系统的期望行为无关；它与用户的期望行为有关。”我对这个声明有点困惑，因为它似乎与 Dan 对 WRT“行为”（系统与用户）的定义相矛盾：youtu.be/qWsnmx45734?t=51s
@TonyD 对于单元级 BDD，用户是另一个类。想象一下你就是那个班级。弄清楚你想如何使用你将要编写的课程。你能举个例子吗？如果是这样，这就是 BDD！您正在考虑类的行为将如何为用户（其他类）传递价值，而不是担心它在内部的行为方式。我的评论“这不是真正关于系统的期望行为”是关于美学，而不是关于 BDD，所以我将编辑得更清楚。
啊。是的，是我对“它”这个主题的误解让我失望了。您的编辑将其清除。谢谢！

【解决方案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

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

你的例子

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

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

【讨论】：

嗨凯尔，你的例子很有帮助，我明白我的场景并不是真正的业务。正如@Lunivore 所建议的那样，我可能会将此作为较低级别的测试并将GWT 转换为cmets。关于您的示例的一个问题：And the ticket is not scanned at "LGW" 应该以 But 而不是 And 开头吗？
它可以是 And 或 But 在这种情况下都有意义。但是，在您这么说之后，我的直觉告诉我将其更改为 But 仅仅是因为它引用了一个否定的前提条件而不是一个积极的前提条件。在使用 And 和 But 时，这完全取决于偏好

【解决方案3】：

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

【讨论】：