①TDD 是测试驱动开发（Test-Driven Development），它同样也是敏捷开发的一种方法论。TDD 是再开发代码之前，先编写单元测试用例，用测试的代码确定要编写什么样的代码。它的整个思路就是通过测试来驱动整个软件开发的进度，当然这对测试人员来说是一个更高的要求和标准；
②优点：
在任意一个开发节点都可以拿出一个可以使用，含少量 bug 并具一定功能和能够发布的产品；
保障代码的正确性，能够迅速发现、定位 bug。针对关键代码的测试集，以及不断完善的测试用例，为迅速发现、定位 bug 提供了条件；
缺点：
增加代码量。测试代码是系统代码的两倍或更多，但是同时节省了调试程序及挑错时间；
③步骤：
1、先写测试代码，并执行，得到失败结果；
2、写实现代码让测试通过；
3、重构代码，并保证测试通过；
4、反复实行这个步骤 测试失败 -> 测试成功 -> 重构；
④原则：
1、测试隔离：不同代码的测试应该相互隔离，对一块代码的测试只考虑此代码的测试，不要考虑其实现细节；
2、及时重构：无论是功能代码还是测试代码，对结构不合理，重复的代码等情况，在测试通过后，及时进行重构；
3、可测试性：功能代码设计、开发时应该具有较强的可测试性。其实遵循比较好的设计原则的代码都具备较好的测试性。比如比较高的内聚性，尽量依赖于接口等；
4、先写断言：测试代码编写时，应该首先编写对功能代码的判断用的断言语句，然后编写相应的辅助语句；
5、测试驱动：这个比较核心。完成某个功能，某个类，首先编写测试代码，考虑其如何使用、如何测试。然后在对其进行设计、编码；
6、测试列表：需要测试的功能点很多。应该在任何阶段想添加功能需求问题时，把相关功能点加到测试列表中，然后继续手头工作。然后不断的完成对应的测试用例、功能代码、重构。一是避免疏漏，也避免干扰当前进行的工作；
7、小步前进：把所有的规模大、复杂性高的工作，分解成小的任务来完成，每个功能的完成就走测试代码－功能代码－测试－重构的循环。通过分解降低整个系统开发的复杂性；
8、一顶帽子：开发人员完成对应的工作时应该保持注意力集中在当前工作上，而不要过多的考虑其他方面的细节，保证头上只有一顶帽子。避免考虑无关细节过多，无谓地增加复杂度；
⑤Tips：TDD 需要大量的实践，并且对参与人员的素质要求相当高，在现在互联网公司中这样的方式还算是比较少的，或许在这种快节奏的变化多端的巨型互联网产品中，项目更加注重商业和流程。当然如果是小而精尖的团队可以考虑这样的模式
（参考：www.jianshu.com/p/79a219ecd…
