TDD 的三项法则
- 先写单元测试代码，然后再编写被测试代码。
- 一个单元测试失败，就停止编写测试代码，即保证每一次都是成功的，从这角度说，可以保证后续集成测试出现的 bug 变少。
- 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。即写了必要的产品代码，就别写了，再先写测试代码，再写产品代码，不要多余。
TDD 的优势
- 确定性：就是无论改了什么，只要保证单元测试都覆盖到，只要保证单元测试都通过了，就可以确定代码没什么问题了，可以交付。
- 缺陷注入率：因为每写一点代码都要先测试，所以能够减少引入的缺陷。
- 勇气：看到糟糕的代码，为什么不敢修改？因为怕引起其他问题。被戳中了，如果有一套值得信赖的测试，那就可以打消这顾虑，可以放手去整理代码。不再惧怕整理代码时，就会去整理代码，然后代码便易于理解、修改和扩展。
- 文档：单元测试即文档，如果是遵循 TDD 的程序，只要看到单元测试，就能明白函数如何调用，什么参数，对象如何创建。
- 设计：比如一个函数调用其他函数，因为要单元测试，必须将两个函数解耦。测试先行，会迫使你去考虑什么是好设计。事后写测试是防守，先写测试是进攻，强迫自己必须写出能够单元测试的解耦的代码。
- 专业人士的选择：TDD 是专业人士的选择。是提升代码确定性、给程序员鼓励、降低缺陷率、优化文档和设计的原则。
好像有点被说服了。
TDD 的局限
规则不可教条，根据实际情况判断，若真不适合，也不必遵循，反正现在写 Android 代码我感觉不太适合，简单的单元测试可以，稍微复杂点的就要运行到手机上，需要虚构许多东西，挺繁琐的，不像直接在电脑上编译运行。这实践留待以后做其他的项目吧。
