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

TDD使您考虑所需的行为，因此术语“行为”比术语“测试”更有用。 BDD是“测试驱动开发”，其词汇集中于行为而不是测试。

用Dan North的话来说，“我发现从测试思维到行为思维的转变是如此深刻，以至于我开始将TDD称为BDD或行为驱动开发。” TDD着重于某些事物的工作方式，BDD着重于我们为何要构建它。

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

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

故事框架

作为[角色]

我想要[功能]

这样[好处]

这意味着，“执行功能时，最终的收益是给扮演角色的人。 ‘

BDD进一步回答以下问题-

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

示例框架

给定一些初步的背景，

当事件发生时，

然后确保一些结果。

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

因此，该示例显示了系统的预期行为。这些示例用于说明系统的不同方案。

故事和场景

让我们考虑一下Dan North关于ATM系统的以下图示。

故事

作为客户，

我想从ATM取款，

这样我就不必在银行排队等候。

情境

这个故事有两种可能的情况。

方案1-帐户已贷记

鉴于该帐户已贷记

而且卡是有效的

而且分配器中有现金

当客户要求现金时

然后确保该帐户已借记

并确保现金分配

并确保卡已归还

方案2-帐户透支超过透支额度

鉴于帐户已透支

而且卡是有效的

当客户要求现金时

然后确保显示拒绝消息

并确保不分配现金

并确保卡已归还

在两种情况下，事件都是相同的，但是上下文是不同的。因此，结果是不同的。

开发周期

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

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

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

步骤3-实现最小代码以通过该较低级别的示例，请参见绿色。

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

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

注意–请记住以下几点-

• 红色/绿色状态是允许状态。

• 当低级测试变为绿色时，您有权编写新示例或重构现有实现。在重构的上下文中，您不得添加新的功能/灵活性。

• 当您的低级测试变为红色时，您仅具有编写或更改实现代码的权限，以便使现有测试变为绿色。您必须抵制编写代码以通过您的下一个测试(不存在)或实现您认为不错的功能(客户不会要求)的冲动。