http://www.theserverside.com/news/thread.tss?thread_id=32394#160253
Why do I like TDD?
1) by the nature of software engineering any code needs refactoring. Having code covered with unit-tests, gives me confidence during the refactoring. I do not know any other reliable way of having the same kind of confidence. Without the confidence, I would be afraid to do refactorings often, which would make the software product of lesser quality.
1)本质上，软件开发中一切代码都需要重构。经过单元测试覆盖的代码可以让我拥有信心去重构。我也不知道还有什么其他办法能够让我获得如此的信心。如果没有信心，那么我就不太敢经常的重构，这也必然影响代码的品质。
2) Due to the nature of unit-tests (emphasize: unit), it is impossible to test a "badly-smelling" code. In order to be able to unit-test your code, it has to be cleaner, and better designed: short, focused methods, writing to Interfaces, lously coupled etc.
2）由于单元测试的自然特性（注意是单元测试），无法对具有“坏味道”的代码进行单元测试。而为了能够顺利的对你的代码进行单元测试，那么你的代码就会逐渐的变得更加清晰、设计更加完善：代码短小、专注方法、针对接口编程、降低耦合等。
I think, this might not have been something that was foreseen initially but discovered later. My guess is, initially, people just wanted to make computer do what it is best for - repetitive work (in this case - testing) and have code test the application, not humans. But as a "byproduct" they noticed that testing requires design improvement, too. When they discovered it, somebody smart-enough had an idea - if it is so, why not write tests first? Design is supposed to come before the implementation and if tests affect design, it makes sense to write them before the implementation, too.
我想，也许单元测试的提倡者事前也未曾会预料到它能够带来这已经证实了的益处。我想，刚开始人们也就只是希望发挥计算机的特点，让它完成重复性的工作（这里是指测试），而不再需要人去进行测试。但是他们发现了“副产品”―测试需要更好的设计。接着，他们中的杰出者提出了一个全新的想法－既然如此，那何不事先写好测试呢？设计是应该在代码实现之前的，而如果测试可以影响设计，那么何不也将测试在代码实现之前进行编写呢？
And the TDD started...
于是TDD开始了…….。
====================================
http://www.theserverside.com/news/thread.tss?thread_id=32394#160294
I think I agree with some of the objections raised with TDD, but the problem seems more with how people use it than a basic flaw in the concept. The 2 primary objections raised are:
1. There is a lot of test-centric coding with less focus on ensuring overall business requirement is fulfilled.
2. Developers seem to think that having run the product through the Unit tests ensures that the product is well-tested and production ready.
我对TDD所引起的问题非常的同意，但是问题更在于人们如何解决它，而不是仅停留在基本的观念上。TDD主要引起的问题是：
1、 存在着太多的“以测试为中心”的代码，而更少的关注于整体的业务需求。
2、开发者好像开始认为跑遍单元测试就可以保证产品的可测试和产品的质量。
All that TDD should be expected to do is run a sanity check at the end of a new build to ensure that the contracts that each unit of code is supposed to fulfill have not been broken. You still need to go through your entire QA cycle to ensure you have a functional product. So, the automated unit tests are just additional checks and do not replace QA. But, unfortunately I have seen situations where people believe that once they have a proper build and unit tested they can reduce the time they spend in QA. Not really true!!! It just ensures that if the unit tests were written properly, the quality of the code reaching QA will be a little better.
所有的TDD能做的是在整个项目构建结束之后完成一个检查工作，保证原有的单元之间的契约没用被打破。在项目构建完成后，还需要一个质量保证(quality assurance)的过程，以保证整个项目的功能。也就是说自动化测试只是一个附加的检查，而不是对质量保证的全盘替代。但不幸的是，我看到的人们却非如此。他们认为一旦单元测试成功，那么就可以减少QA上面的时间。但事实真的不是这样的。单元测试所能做倒的也仅在于单元测试已经很好的编写完成，代码的质量更容易达到QA的标准。