BDD是第二代的、由外及内的、基于拉(pull)的、多方利益相关者的(stakeholder)、多种可扩展的、高自动化的敏捷方法。它描述了一个交互循环，可以具有带有良好定义的输出（即工作中交付的结果）：已测试过的软件。
简单一点地说，BDD，即行为驱动开发，是开发者通过与产品经理沟通需求，共同定义出满足这些需求的软件需具备的行为(Behaviour)，再以这些行为为驱动(Driven)，编写产品代码(Development)来实现这些行为。BDD的出现，是为了解决测试驱动开发中常遇到的问题，比如：从哪里开始测试，应该测试什么，不应该测试什么等等。BDD源自TDD，但重点不是关于测试，所强调的沟通与协作可以指导更好的做自动化测试。BDD 强调用领域特定语言（DSL, domain specific language）描述用户行为，定义业务需求，而不会关心系统的技术实现。
为什么要BDD？
美国经济解读：
“The hardest single part of building a software system is deciding precisely what to build（开发软件系统中最困难的部分就是准确地说明需要开发什么）” — No Silver Bullet, Fred Brooks
案例一：业务分析人员觉得自己分析的需求已经写的很清晰了，并且跟技术人员进行了足够的沟通，可是开发完 sign off的时候，发现所开发的功能还是跟期望有差距。
案例二：开发团队辛辛苦苦开发完一个功能，满怀信心的去给客户展示的时候，才发现原来客户需求的功能不是这样的。
这些场景是不是似曾相识？为什么会这样？
第一个场景是开发团队内部技术人员跟需求分析人员的理解有偏差，导致大家理解的需求其实是不一样的；
第二个场景是开发团队没有真正理解产品经理／客户所提出来的真实需求，导致开发的产品跟需求不一致。
其实，产生这两个不一致的真正原因是因为不同角色有着不同的领域知识，说着不同的语言，大家在沟通的时候，如果都用自己领域语言，必然会产生沟通代沟，导致理解的不一致性。使用BDD以上两个案例需求和实现不一致的问题就能迎刃而解了。
BDD常用框架
BDD面临的首要问题是如何使用特定的描述性语言来完成需求的描述。目前BDD框架已经比较多，比如 JBehave,Cucumber,Concordian 等，每一种框架都使用自己的一套DSL。
使用Calabash实现BDD开发
Calabash是基于Cucumber框架实现的一套跨平台的BDD开发框架，可以方便的实现在iOS平台和Android平台上的自动化UI接受测试。下面将通过一个简单的例子来讲解整个Calabash的配置开发步骤（以XCode为例）。
功能描述：检验登录密码是否合法--在登录界面，用户输入完账号密码，当用户点击“登录”按钮的时候，检验用户的密码是否大于等于6位，如果小于，出现错误提示“密码不能少于6位”
安装Calabash沙盒：打开终端，在终端里运行下面的脚本。该脚本将会在沙盒中安装配置Ruby 2.1.5-p273, Calabash iOS, Calabash Android以及Xamarin Test Cloud. (备注：Calabash沙盒会忽略电脑上的默认Ruby配置，不对其造成任何影响，所有相关文件都存在$Home/.calabash/sandbox中)
curl-sslhttps://raw.githubusercontent.com/calabash/install/master/install-osx.sh|bash
安装成功后，terminal中将出现下列的提示。
新建工程：创建一个只有登录界面的新工程，为登录界面嵌入一个navigation controller，title为“点融网”，登录界面中包含了一个“账号”输入框，“密码”输入框，“登录”按钮以及一个“错误信息”label。实现逻辑，如果用户输入的密码不合法，提示“错误信息“。
引入Calabash库
a) 在终端cd至工程根目录
b) 在终端输入calabash-sandbox
c) 在沙盒中输入calabash-ios download
d) 用XCode打开工程，选择TARGETS->工程->Building Settings-> Other Linker Flags，双击Debug，在对话框中粘贴下面字符串
-ObjC -force_load "$(SOURCE_ROOT)/calabash.framework/calabash" -framework CFNetwork
6.为iOS工程创建一个Calabash测试用例
在沙盒中输入下面命令，执行该命令时会出现一系列的一般疑问句，全部选y就可以了。命令执行完成后，工程根目录下会出现一个features的文件夹，里面存放的就是将来会被自动测试的feature们
根据Gherkin的语法规则(类似于自然语言)在sample.feature文件中定义测试用例并保存，如下面所示。作者在这里只写了该feature中的一个scenario，即密码太短的检验；读者可以尝试在后面加上另外一个scenario，即检验是否包含至少一个大写字母
在沙盒中输入Cucumber，真机或者模拟器会自动加载该工程，逐步模拟feature中所描述的行为，运行结果如下，表示测试通过。
总结
BDD是一种以沟通为核心的敏捷软件开发方法，通过开发者与产品既得利益者（或其代表）之间不断的沟通，用一种双方都能理解的语言来定义和明确features，这些features在将来既可以通过框架（如Calabash）来转换成自动化的测试用例，又可以作为简化版的文档以供查阅。
当然，世界上没有最完美的方法，只有最适合自己的方法。BDD有一些很明显的优点，比如可以确保开发出来的产品更符合需求、缩短开发阶段结束之后的测试周期、features确定完后更高的开发效率等；然而缺点也是昭然若揭的，即项目前期会有大量的时间消耗在逐一讨论feature上面，本来程序员们在项目开启之后的第二周就可以开始coding了，结果因为讨论，也许会拖到第三周甚至第四周之后才能开始coding。不幸的是，对于目前的大多数互联网公司来说，尤其是初创型公司，时间就是生命。所以在使用BDD方法之前需三思而后行，是相信磨刀不误砍柴工还是更相信速度制胜。
本文作者：汪春建（点融黑帮），点融资深软件工程师，从事Mobile开发8年，熟悉Window Moblie ,Symbian ,Android 及iOS等移动平台软件开发。喜欢研究新技术，业余时间会阅读开源代码，学习优秀的代码风格，编程思想，并将所学知识融入工作中，提高工作效率。
