1. TDD的简介
TDD 是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD 是 XP（Extreme Programming）的核心实践。
TDD 有广义和狭义之分，常说的是狭义的 TDD，也就是 UTDD（Unit Test Driven Development）。广义的 TDD 是 ATDD（Acceptance Test Driven Development），包括 BDD（Behavior Driven Development）和 Consumer-Driven Contracts Development 等。
2.TDD的编码方式与传统的编码方式
TDD编码方式：
- 先分解任务，分离关注点。
- 列出示例，用实例化需求，澄清需求细节。
- 写测试，只关注需求，程序的输入输出，不关心中间过程。
- 写实现，不考虑别的需求，用最简单的方式满足当前这个小需求即可。
- 重构，用手法消除代码里的坏代码。
- 写完，手动测试一下，基本没什么问题，有问题补个用例，修复。
- 代码整洁且用例齐全，信心满满地提交。
传统编码方式：
- 需求分析，比较难分析到清楚细节，但是时间问题，不得不按粗略的理解编码。
- 在编码过程中发现需求细节不明确，需要同业务人员进行需求确认。
- 可能需要确认多次需求才能实现业务逻辑。
- 一堆代码编写完后，在运行和测试时可能会出现很多bug，所以需要大部分时间去调试和修改。
- 转测试，QA 测出 bug，debug， 打补丁
3.使用TDD的好处
适当减少了开发者的工作量
通过明确的流程，让我们一次只关注一个点，思维负担更小，编码测试方便。
单元测试保证代码质量
TDD 的好处是覆盖完全的单元测试，为产品代码编写时提供了比较方便的测试，使得开发人员面对需求变化时比较方便的做出相应的修改，此外也能够方便的实现改善代码的设计。这样开发人员提交的代码质量就比较高。
方便理解业务需求
先写测试可以帮助我们去熟悉我们的业务需求，并提前发现需求细节，而不会时编码工作进行一半后才发现不明确的需求。
快速反馈
有很多人说 TDD 时，我的代码量增加了，所以开发效率降低了。但是，如果没有单元测试，就需要手工测试，这样就会花很多时间去准备数据，启动应用，跳转界面等，想要得到反馈的结果会比较慢。换言之，快速反馈是单元测试的好处之一。
4.TDD的三条规则
- 除非是为了使一个失败的 unit test 通过，否则不允许编写任何产品代码
- 在一个单元测试中，只允许编写刚好能够导致失败的内容（编译错误也算失败）
- 只允许编写刚好能够使一个失败的 unit test 通过的产品代码
