TDD
Test Driven Development 测试驱动开发
大致思想是：在编码之前，先写测试代码，测试代码就绪后，编写代码，再去用测试代码去验证编写代码，及时修改完善逻辑。
具体实施过程中，可以看作两个层次：
-
UTDD
Unit Test Driven Development 即单元测试驱动开发
编码之前写测试单元，然后再去写产品代码。产品代码通过单元测试后，再进入下一环节
好处：开发人员不会过于懒散，不会随意的去写代码，提高了代码质量。并且因为先写测试单元，有利于解决一些思维上的Bug -
ATDD
Acceptance Test Driven Development 验收测试驱动开发
在编写产品代码之前，明确需求的验收标准。这样开发人员会比较明确如何写代码。同时不会造成开发出来的需求和产品或者测试理解的不一致
从ATDD演化出来的一种具体开发模式是BDD(Behavior Driven Development 行为驱动开发)，BDD将验收标准等更加细致的列出来。
个人对TDD的一些理解：
好处：
- 测试在前，编码在后，有利于提高编码效率
- 在相对较早阶段将开发，产品，测试对需求的理解进行了统一，降低了沟通成本。
- 减少了开发的思维障碍，有利于提高代码质量
-为测试提供了一些标准，提高工作效率 - 减少了重构代码的成本
不好处：
- UTDD 落实起来相对较难。开发工作量会倍增，学习成本也需要一些
- 无法真正做到测试在前，对于验收测试驱动，可能在快到开发提测阶段测试才完成验收标准。
