TDD可以带来好处

提供明确的目标:
你很清楚, 一旦结束(测试通过), 你的工作就完成了(假设你的测试写的很好). 测试代码会为代码建立一个自然的边界, 使你把重点集中在当前任务上. 一旦测试通过, 就有确切的证据证明你的代码能工作. 相对于人工的测试用户界面或者比较日志文件中的结果,  在一个xUnit框架中运行自动化测试, 速度要快几个数量级. 大多数xUnit测试的运行只需几微秒, 而且大多数采用TDD的人都会一天运行数次测试. 在许多开发小组中, 将代码上传配置库前, 必须成功地通过测试.

提供文档
你是不是经常遇到看不懂的代码? 这些代码可能没有任何文档说明, 而且开发代码的人可能早就走了(或者去度假了). 当然看到这种代码的时间往往也很不合时宜, 可能是凌晨3点, 也可能有位副总在你旁边大声催促着赶快解决问题, 这样要想花些时间来愿作者的意图就更困难了. 我们见过一些好的单元测试文档, 它们会指出系统要做什么. 测试就像原开发人员留下的记号, 可以展示他们的类具体是怎么工作的.

改善设计
编写测试能改善设计. 测试有助于你从界面的角度思考, 测试框架也是代码的客户. 测试能让你考虑得更简单. 如果你确实遵循了"尽量简单而且行之有效"的原则, 就不会写出篇幅达几页的复杂算法. 要测试的代码通常依赖性更低, 而且相互之间没有紧密的联系, 因为这样测试起来更容易. 当然, 还有一个额外的作用, 修改起来也会更容易!

鼓励重构
利用一套健壮的测试集, 你能根据需要进行重构. 你是不是经常遇到一些不知是否该修改的代码? 种种的顾虑让你行动迟缓, 过于保守, 因为你不能保证所做的修改会不会破坏系统. 如果有一套好的单元测试集, 就能放心的进行重构, 同时能保证你的代码依然简洁.

提高速度
编写这么多测试会不会使开发速度减慢呢? 人们经常会以速度(或开发开销)作为反对进行TDD和使用xUnit框架的理由. 所有的新的工具都会有学习曲线, 但是一旦开发人员适应了他们选择的框架(通常只需要很短的时间), 开发速度实际上会加快. 一个完备的单元测试集提供了一种方法对系统完成回归测试, 这说明, 增加一个新特性之后, 你不必因为怀疑它会不会破坏原系统而寝食难安.

提供反馈
单元测试还有一个经常被忽略的优点, 即开发的节奏. 尽管看上去好像无关紧要, 但通过测试之后你会有一种完成任务的成就感! 你不会成天地修改代码而没有任何反馈, 这种测试-代码-测试的方法会鼓励你动作幅度小一些 通常修改一次代码的时间仅仅几分钟而已. 这样你不会一下子看到冒出一大堆新的特性, 而只是让代码每次前进一小步.