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)本質(zhì)上，軟件開發(fā)中一切代碼都需要重構(gòu)。經(jīng)過單元測(cè)試覆蓋的代碼可以讓我擁有信心去重構(gòu)。我也不知道還有什么其他辦法能夠讓我獲得如此的信心。如果沒有信心，那么我就不太敢經(jīng)常的重構(gòu)，這也必然影響代碼的品質(zhì)。
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）由于單元測(cè)試的自然特性（注意是單元測(cè)試），無法對(duì)具有“壞味道”的代碼進(jìn)行單元測(cè)試。而為了能夠順利的對(duì)你的代碼進(jìn)行單元測(cè)試，那么你的代碼就會(huì)逐漸的變得更加清晰、設(shè)計(jì)更加完善：代碼短小、專注方法、針對(duì)接口編程、降低耦合等。
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.
我想，也許單元測(cè)試的提倡者事前也未曾會(huì)預(yù)料到它能夠帶來這已經(jīng)證實(shí)了的益處。我想，剛開始人們也就只是希望發(fā)揮計(jì)算機(jī)的特點(diǎn)，讓它完成重復(fù)性的工作（這里是指測(cè)試），而不再需要人去進(jìn)行測(cè)試。但是他們發(fā)現(xiàn)了“副產(chǎn)品”―測(cè)試需要更好的設(shè)計(jì)。接著，他們中的杰出者提出了一個(gè)全新的想法－既然如此，那何不事先寫好測(cè)試呢？設(shè)計(jì)是應(yīng)該在代碼實(shí)現(xiàn)之前的，而如果測(cè)試可以影響設(shè)計(jì)，那么何不也將測(cè)試在代碼實(shí)現(xiàn)之前進(jìn)行編寫呢？
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.
我對(duì)TDD所引起的問題非常的同意，但是問題更在于人們?nèi)绾谓鉀Q它，而不是僅停留在基本的觀念上。TDD主要引起的問題是：
1、 存在著太多的“以測(cè)試為中心”的代碼，而更少的關(guān)注于整體的業(yè)務(wù)需求。
2、開發(fā)者好像開始認(rèn)為跑遍單元測(cè)試就可以保證產(chǎn)品的可測(cè)試和產(chǎn)品的質(zhì)量。
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能做的是在整個(gè)項(xiàng)目構(gòu)建結(jié)束之后完成一個(gè)檢查工作，保證原有的單元之間的契約沒用被打破。在項(xiàng)目構(gòu)建完成后，還需要一個(gè)質(zhì)量保證(quality assurance)的過程，以保證整個(gè)項(xiàng)目的功能。也就是說自動(dòng)化測(cè)試只是一個(gè)附加的檢查，而不是對(duì)質(zhì)量保證的全盤替代。但不幸的是，我看到的人們卻非如此。他們認(rèn)為一旦單元測(cè)試成功，那么就可以減少Q(mào)A上面的時(shí)間。但事實(shí)真的不是這樣的。單元測(cè)試所能做倒的也僅在于單元測(cè)試已經(jīng)很好的編寫完成，代碼的質(zhì)量更容易達(dá)到QA的標(biāo)準(zhǔn)。