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的標準。