BDD也叫行为驱动开发，是根据软件系统的外部行为验证软件是否正常工作，多是以自动化的方式。

TDD是测试驱动开发，测试驱动开发的特点是先定义测试用例，再开发功能，它可以保证代码的准确性。但是如果开发者只完成了测试的代码，而忽略的对实际需求的关注，也是不完善的，这就促成了BDD的出现。

BDD(行为驱动开发)借助于DDD(领域模型驱动)去加强TDD的测试关注点。

BDD是Dan North针对TDD难点之处的解决方案。在他的一篇文章中，介绍了主要的TDD的弊端，其中一个主要原因就是TDD中的测试还是停留在"测试"的目的。

这样会导致一个错误的结果，大家以为测试用例通过了就代表整个应用就没有问题。

Dan North 认为应把注意力放在用户“操作行为”而不是“测试”上，用这种方式解决在TDD时产生的一些疑问。不久后在2003年，基于JUint产生了第一个BDD框架，取名JBehave。

BDD是如何工作的

BDD的测试用例是由人们的自然语言写的，其中使用一些关键字来规范用户行为。BDD的测试用例类似：

Scenario: Add a product to the shopping basket

Given I am viewing the article page

When I click the “add to cart” button

Then the shopping cart counter increases

And the item appears in the shopping cart

红色开始的部分是BDD框架的测试步骤，而Scenario则是测试用例，测试用例的第一步一般是Given开始表明测试的前提条件。When 给定一个测试执行条件，Then为预期结果，通过Given，When，Then的方式就把整个测试用例串联了起来。所有这些关键字都有对应的中文，这意味着你可以写一个等价的全中文用例。

如果测试用例中还有其它操作，我们一般用“And”或中文“而且”将其连接起来。

所有的操作步骤组织在一起成为测试用例(Scenario)，不同的测试用例组织在一起定义为Feature文件。这些Feature文件放在文件中，文件结尾以.feature命名。

这些文件定义好，开发人员根据描述的场景实现具体的操作步骤。

为什是BDD？

BDD使开发人员更容易确定测试的范围，对BDD来说，重点已不再是实现测试某个类或函数，而是确保功能按照用户的期望运行。

BDD的另一个主要优势是使用了所有相关方都能理解的语言，参与方不需要事先具备编程知识，只需要简单介绍就能理解。

由于这一点，参与产品开发的所有各方都能够理解正在进行的工作以及所涉及的功能。

在BDD测试失败的情况下，整个团队能够定位出错的组件，并能够为此提供新的建议，在这些想法的基础上进行总结。

BDD还允许围绕领域设计产品测试，有效地为最终用户增加价值的测试。

BDD测试是从应用程序使用者，也就是用户角度出发，因此促使所有团队围绕应用程序的功能和行为进行工作，而不是强制它们围绕内部组织具体代码工作。

最后，BDD的另一个优点是它允许重用大部分测试代码，因为测试的常见步骤(登录、单击按钮……)可以标准化并重用多次。

为什么必须使用BDD？

BDD 一大好处是，它将不确定的用户故事行和验收标准，转换为规范的测试场景，生成文档、自动测试和活动规范的示例。

换句话说，它使每个项目参与者对项目的认知更新到同一个层次，并确保没有关于软件系统的行为或它对业务的影响方面的误解。

至少，BDD价值是让项目相关的业务人员积极参与到软件系统项目中。这非常棒，因为它极大地减少了在软件系统开发过程中常见的一些浪费，同时保证它们按时、按预算交付。

主动发掘

设想您的团队最近完成的软件系统项目。

从启动到交付用了多长时间？目前，假设您第二次开发同样一个项目，而所有的内容跟前一次都是一样的，只是第二次开发中，您的团队掌握了他们在最初的项目中学到的所有内容。

第二个项目需要多长时间才能完成？时间大大缩短，是吗？这个例子告诉我们，学习是软件系统开发中的约束。

行为驱动开发提供的一个优势是主动的发现知识：尽可能快地学习，以发现并解决项目上的约束，这可以保证质量并按时交付。

深入思考

大多数软件系统开发小组都熟悉用户故事和验收标准。例如，对微博这个应用，用户故事可以描述一个用户将回复另一个用户的微博。可接受性标准可以帮助概括出具体的实用性，比如在用户的个人资料上有一个回复按钮。问题是这两个工具（用户故事和验收标准）永远不会探索任何未知。

深入思考意味着就用户故事和接受标准进行对话，对话的结果是生成一些具体的例子。

例如，用户可能会问：我的回复是否可以出现在我的微博首页中，让任何人看到？最初的用户描述和验收标准可能没有这样的解决方案，但是，它显然可能对一般应用程序的设计产生巨大的影响。

谁应该参与其中?

深入思考的过程应该包括尽可能多的备选团队成员，因为您希望他们提供关于特定经验领域的见解。

开发人员可能会在真正的技术层面上考虑选项，而领域专家则可以洞察实际客户在实际搜索方面的需求。

所有这些见解对于减少选项的不确定性并最终满足软件的业务目标至关重要。

一些团队成员：

• 领域专家

• 业务分析师

• 用户体验设计师

• 用户

• 开发人员

• 测试人员

• 运维工程师

• 产品经理

保持正确的心态

团队训练可以让每个人都保持正确的心态，来针对未来可能发生的场景进行讨论。

莉兹·基奥(Liz Keogh)提出了一种常见的训练方法，这种方法在一个由3到4个人组成的小组中效果最好，小组成员要在一个非常专用的会议空间里，用白板开会。

这项工作将由在白板上画四栏开始:

• 故事专栏: 所有人都应该讲述一个故事，他们需要遇到的一些缺点，以及他们为解决问题而发现的解答。

• 项目截止: 创建了哪些选项来解决问题，例如关于截止日期或编写错误代码的选择。

• 深入思考: 你可能在更早的时候就发现了可能导致不成熟决策事情，例如，非理性的客户或过于激进的日程表。

• 选项专栏: 举例来说，当市场上出现额外的数据时，您的选择是否会持续更长的时间?

在完成练习后，小组应该讨论采取哪些方法可能有助于他们建立和避免问题。

结论应该是，早期事先考虑周详通常会阻止事情在一开始就发生，我们古话说的好，凡事预则立，不预则废。

总之，BDD是一个强大的工具，能够通过将测试集中在最终产品上而不是代码上，为用户生成真正的价值。

如果您决定采取这一步骤并尝试它，您将看到BDD成为您在软件开发中最好的盟友。