单元测试实践技术(TDD/BDD)
TDD
Test-Driven Development, 测试驱动开发， 是敏捷开发的一项核心实践和技术，也是一种设计方法论。TDD原理是开发功能代码之前，先编写测试用例代码，然后针对测试用例编写功能代码，使其能够通过。看上去很美，但是由于测试驱动开发对开发人员要求较高，更与开发人员的传统思维习惯相违背，因此实践起来有一定的困难。
TDD方法的基本前提是： 你的开发基本是由若干(单元)测试驱动的，你第一次编写测试，然后运行它们。很明显，测试失败了，那么下一步就是要编写代码使测试通过。但在实践中可能项目开发人员花x%的时间来写新的测试代码，而不重视产品代码，那么我们就要问问其中的意义何在了，这只是在制造更多行的代码和更多的bug。给人最大的印象是：开发人员在时间压力下试图创建能通过‘测试’的东西，就此而已， 100%的单元测试覆盖率纯粹是在浪费精力。
BDD
Behavior-Driven Developmen， 行为驱动开发。行为驱动开发的根基是一种"通用语言"。 这种通用语言同时被客户(PM, UE)和开发者用来定义系统行为。使用通用语言，客户和开发者一起定义出系统行为，从而做出符合客户需求的设计。定义系统行为成为主要工作，而对系统行为的描述则变成了测试标准。
书写格式：
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 [应该退还银行卡]