测试驱动开发 VS 行为驱动开发

　测试驱动开发（Test Driven Development,英文缩写TDD）是极限编程的一个重要组成部分，它的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完成全部功能的开发。代码整洁可用(clean code that works) 是测试驱动开发所追求的目的

优点

　　测试驱动开发有很多优点：

　　(1)完工时完工。表明开发人员可以很清楚的看到自己的这段工作已经结束了，而传统的方式很难知道什么时候编码工作结束了。

　　(2)全面正确的认识代码和利用代码，而传统的方式没有这个机会。

　　(3)开发小组间降低了交流成本，提高了相互信赖程度。

　　(4)避免了过渡设计。

　　(5)系统可以与详尽的测试集一起发布，从而对程序的将来版本的修改和扩展提供方便。

　　(6)逃避了设计角色。对于一个敏捷的开发小组，每个人都在做设计。

　　(7)大部分时间代码处在高质量状态，100％的时间里成果是可见的。

　　(8)由于可以保证编写测试和编写代码的是相同的程序员，降低了理解代码所花费的成本。

　　(9)为减少文档和代码之间存在的细微的差别和由这种差别所引入的Bug作出杰出贡献。

　　(10)在预先设计和紧急设计之间建立一种平衡点，区分哪些设计该事先做、哪些设计该迭代时做提供了一个可靠的判断依据。

　　(12)发现比传统测试方式更多的Bug。

开发过程

　　概括起来，测试驱动开发的基本过程如下：

　　(1) 明确当前要完成的功能。可以记录成一个 TODO 列表。

　　(2) 快速完成针对此功能的测试用例编写。

　　(3) 测试代码编译不通过。

　　(4) 编写对应的功能代码。

　　(5) 测试通过。

　　(6) 对代码进行重构，并保证测试通过。

　　(7) 循环完成所有功能的开发。

　行为驱动开发（Behavior-Driven Development）（简写BDD）
　　BDD 作为一种设计方法，可以有效的改善设计，并在系统的演化过程中为团队指明前进方向。
　　行为驱动开发的根基是一种“通用语言”。这种通用语言同时被客户和开发者用来定义系统的行为。由于客户和开发者使用同一种“语言”来描述同一个系统，可以最大程度避免表达不一致带来的问题。表达不一致是软件开发中最常见的问题，由此造成的结果就是开发人员最终做出来的东西就不是客户期望的。使用通用语言，客户和开发者可以一起定义出系统的行为，从而做出符合客户需求的设计。但如果光有设计，而没有验证的手段，就无法检验我们的实现是不是符合设计。所以 BDD 还是要和测试结合在一起，用系统行为的定义来验证实现代码。
　　行为驱动开发是测试驱动开发的进化，但关注的核心是设计。行为驱动开发中，定义系统的行为是主要工作，而对系统行为的描述则变成了测试标准。在行为驱动开发中，我们需要使用通用语言来定义系统行为。而通用语言，实际上是一个最小化的词汇表。我们使用这些词汇来书写故事。选入词汇表的词汇必须具有准确无误的表达能力和一致的含义。例如“系统”这个词就不符合要求，因为在不同的语境（又称为上下文 Context）中，“系统”一词具有不同的含义。而“自动提款机”则明确标识了一个没有歧义的事物。
　　书写格式：
　　Story: 标题 （描述故事的单行文字）
　　As a [角色]
　　I want [特征]
　　So that [利益]
　　（用一系列的场景来定义验证标准）
　　Scenario 1: 标题 （描述场景的单行文字）
　　Given [上下文]
　　And [更多的上下文]...
　　When [事件]
　　Then [结果]
　　And [其他结果]...
　　实例：
　　Story: 帐户持有人提取现金
　　As an [帐户持有人]
　　I want [从 ATM 提取现金]
　　So that [可以在银行关门后取到钱]
　　Scenario 1: 帐户有足够的资金
　　Given [帐户余额为 $100]
　　And [有效的银行卡]
　　And [提款机有足够现金]
　　When [帐户持有人要求取款 $20]
　　Then [提款机应该分发 $20]
　　And [帐户余额应该为 $80]
　　And [应该退还银行卡]