TDD的全称(Test Driver Development)测试驱动开发.开发要以测试为驱动。 编码之前,测试先行.很多没有写过单元测试的开发者会想代码都没有,我连要测的对象都没有啊, 怎么写单元测试?(我们可以通过先写伪代码,或者建模来解决这个问题,这样我们站在用户的角度去开发, 尽早发现遇到的问题,也不会遗漏功能)
1.你会站在用户的角度去看你将要完成的产品，你要尽可能想到用户所有进行的操作。 而不是从程序员的角度想用户应该会如何去使用我们的产品。
2.单元测试用例是在对功能进行测试,在写代码之前先写测试用例, 可以对我们编写代码提供指导性的参考,防止我们漏掉一些功能,或者开发的功能和实际需求不一致.
3.它让开发者对自己代码有了信心，因为事先写好的单元测试用例都通过了。
4.在更改代码后,开发者跑单元测试用例没有通过,开发者能精确的定位Bug,并轻而易举的解决Bug.
5.一套完备的测试用例帮助开发者(把关),开发者就可以十分安全的使用(重构). 重构改变的是代码的内部结构,而不会改变外部接口功能. 测试用例是保证我们在进行重构时, 不会影响到代码的外部接口功能. 让开发者进行的重构是十分安全的.
6.安全的重构开发者,在必要时候你还可以痛痛快快的对代码做一场大的变革.让代码变得干净了,扩展性、可以维护性以及易理解性.
TDD有这么多好处,它需要开发者有写出完善的测试用例的能力(这项能力是长期理论与实践的结合体),否则你将会吃了亏编写了一大堆测试用例,却没有用到点子上.可怕的是,你还对你“测试通过”的糟糕的代码满怀信心. 也可能你创造无尽的条件中,会觉得测试用例很难写.
TDD的主旨是高效，可能这个高效不是非常高的开发速度。
TDD的思想是以测试推动开发进程. 因为我们在软件开发之前,每个程序单元的功能都已经确定了.开发者在理解完整个程序需求以后如果直接进行开发,可能会因为考虑不很周全,似乎功能实现的没有问题,但是其中却可能隐藏着非常可怕的Bug. TDD促使开发者先根据程序单元的功能编写测试代码,就像是先建一个模型, 然后向里面浇注合适功能的代码. 最后满足所有的测试验证并且正常通过测试,这个程序单元才算完成.
消除了开发人员主观性的对程序单元健壮性的评估,更客观的验证每一个程序单元的功能实现以及可能出现的Bug. 当然这些操作都需要有大量的代码支持,所以费事是在所难免的.但是这点"费事"与健壮性非常强的代码相比,大多数人还是偏向于使用TDD。