BDD - BDD 方式的 TDD

---

在 TDD 中，术语“验收测试”具有误导性。验收测试实际上代表了系统的预期Behave。在敏捷实践中，强调整个团队的协作以及与客户和其他利益相关者的互动。这就产生了使用项目中每个人都容易理解的术语的必要性。

TDD 让您思考所需的Behave，因此术语“Behave”比术语“测试”更有用。BDD 是测试驱动开发，其词汇重点关注Behave而不是测试。

用 Dan North 的话说，“我发现从测试思维到Behave思维的转变是如此深刻，以至于我开始将 TDD 称为 BDD，即Behave驱动开发。” TDD 专注于某些东西如何工作，BDD 专注于我们构建它的原因。

BDD 回答了开发人员经常面临的以下问题 -

这些答案导致故事框架如下 -

故事框架

作为[角色]

我想要[功能]

这样[好处]

这意味着，“当执行某项功能时，所产生的好处是扮演该角色的人。” '

BDD 进一步回答了以下问题 -

这些答案导致示例框架如下 -

示例框架

给定一些初始背景，

当事件发生时，

然后确保一些结果。

这意味着，“从最初的背景开始，当特定事件发生时，我们知道结果应该是什么。”

因此，该示例显示了系统的预期Behave。这些示例用于说明系统的不同场景。

故事和场景

让我们考虑以下由 Dan North 绘制的有关 ATM 系统的插图。

故事

作为客户，

我想从 ATM 机提取现金，

这样我就不用去银行排队了。

应用场景

这个故事有两种可能的场景。

场景 1 - 账户有信用

鉴于该帐户是贷方

并且卡有效

分配器里装有现金

当顾客要求现金时

然后确保账户已被扣款

并确保分发现金

并确保卡被退回

场景 2 - 账户透支超过透支限额

鉴于账户已透支

并且卡有效

当顾客要求现金时

然后确保显示拒绝消息

并确保不分发现金

并确保卡被退回

两个场景中的事件相同，但上下文不同。因此，结果是不同的。

开发周期

BDD 的开发周期是一种由外而内的方法。

步骤 1 - 编写一个变红的高级（外部）业务价值示例（使用 Cucumber 或 RSpec/Capybara）。（RSpec 用 Ruby 语言生成 BDD 框架）

步骤 2 - 为实现的第一步编写一个较低级别（内部）RSpec 示例，该示例变为红色。

步骤 3 - 实现最低代码以通过该较低级别的示例，看到它变绿。

步骤 4 - 编写下一个较低级别的 RSpec 示例，推动通过步骤 1（变为红色）。

步骤 5 - 重复步骤步骤 3 和步骤 4，直到步骤 1 中的高级示例变为绿色。

注意- 应牢记以下几点 -

• 红/绿状态是许可状态。

• 当您的低级测试通过时，您有权编写新示例或重构现有实现。您不得在重构的情况下添加新的功能/灵活性。

• 当您的低级测试为红色时，您有权编写或更改实现代码，仅用于使现有测试变为绿色。您必须抵制编写代码以通过下一个测试（该测试并不存在）的冲动，或者实现您可能认为好的功能（客户不会问）。