不管黑猫白猫，抓到老鼠就是好猫，TDD是好是坏取决于它是否能解决你的问题。TDD可以帮我解决下面三个问题：
1. 测试代码少
Test later equals test never. 这句话说得太对了，当你面临进度压力的时候，你会通过少写或不写测试节省时间，当QA测试过你的代码之后，你会缺乏足够的动力去补测试，除非有人在下个迭代里专门给你报了一个补单元测试的用户故事。但是如果你使用TDD，测试是先行的，逃都逃不掉。
2. 反馈周期长
很多同学都习惯于把所有的代码先写好再一起测试，所以一些比较复杂的用户故事，可能要经过几天甚至一周的时间才能看到实际的进展和反馈，反馈周期越长，问题就暴露得越晚，修复问题的代价就越大。但是如果使用TDD，每隔几分钟就会有反馈，让你体会尽早反馈的好处，养成尽早反馈的习惯。
3. 垃圾代码多
垃圾代码是指多余的或者过度复杂的代码，很多同学在学了面向对象设计和设计模式之后，很容易在一开始就过度设计，把简单的问题复杂化，当代码成形之后又不敢重构，怕破坏已有的功能，代码不能及时持续地清理，就容易产生很多垃圾代码，日记月累，垃圾成山，会对开发效率产生严重的影响。但是如果使用TDD，设计是逐步演化出来的，重构是在持续发生的，能有效地避免过度设计和代码腐化。
当然解决上面三个问题的方法并不止TDD一家，TDD并不是银弹，能解决所有的问题，但是TDD是一个很好的工具，用好了，它能有效解决上述的问题。今天下午Stike同学批评TDD是“无脑”开发，其实恰恰相反，TDD需要更多的智慧、思考和刻意练习，这可能正是TDD难于推广的主要原因之一吧。
