1、概述
测试驱动开发（Test Driven Development，简称TDD），距今已有20多年的历史。简单来说TDD就是：测试代码优先于产品代码编写，通过测试不断驱动编写完善的产品代码，实现所需的功能。TDD与通常开发模式在角度和思考方式上相反，会让刚接触TDD的人难以接受。
2、TDD所遵循的三个基本原则如下：
-
在编写好失败的单元测试之前，不允许编写任何的产品代码。
对于任何功能需求，都是先从写测试用例入手，为满足测试用例才能去写产品代码。 -
只允许编写刚好能够导致失败的单元测试。只要有一个单元测试失败了，就不要再写测试代码。（无法通过编译也是属于一种失败)
通常在完成产品代码开发后写的测试用例都是尽可能通过的测试用例，很可能因先入为主导致不能正确覆盖测试。相反，TDD编写新的失败测试用例是为了覆盖不同的需求，在测试的深度和捕获错误的灵敏度上会更胜一筹。 -
只允许编写刚好能够使一个失败的单元测试通过的产品代码，不要多写。
编写的生产代码只能是为了使一个失败的单元测试通过，不应编写多余的实现代码。如果过多编写了实现其他功能业务的代码，则违反了TDD的原则。
3、测试驱动开发的基本流程：
先写一段测试代码，很快你会发现还缺少一些类和函数，所以单元测试无法编译，然后再写一些产品代码，让这些测试能够编译成功，然后再回过头接着写单元测试代码。这个循环不断反复，测试代码和产品代码同步增长，互为补充。测试代码之于产品代码，就犹如抗体之于抗原。
4、TDD的优势
-
确定性
TDD模式下测试代码的至少可以覆盖90%的产品代码。任何时刻，代码有任何修改，都必须运行手头有的全部测试。如果单元测试全部通过，那么几乎可以确定修改没有破坏原有的功能，软件足以交付。 -
缺陷注入率非常低。
-
勇气和勇气
看到混乱的代码时，你的第一反应是：“真的是一团糟，这段代码该重构了。”你的第二反应：“我不会去碰它！”因为你知道改动旧代码，风险很高。TDD拥有一套值得信赖的测试，可以完全打消对修改代码的全部恐惧。当程序员不再恐惧整理、优化代码时，系统代码会变得越来越整洁。 -
文档
单元测试即是文档，它们以读者能理解的语言写成，清晰准确地描述了系统最底层的设计细节，形式规整可以运行，便于用户理解系统的功能。它们是最好的系统文档，完全可以替代接口文档。 -
设计
测试代码的一个问题是必须隔离出待测试的代码。如果一个函数调用了其他函数，单独测试它通常会比较困难。为了编写测试，必须找到将这个函数和其他函数解耦的办法，换言之，TDD迫使你去考虑什么是好的设计，促使你对代码的抽取和解耦，利于代码复用。
