TDD的全稱是Test Driver Development，測試驅動開發。就是開發要以測試為驅動。編碼之前，測試先行。代碼都沒有，我如何測試，我連要測的對象都沒有啊？這好像是個問題。
TDD的哲學為我們解答了這個問題：先編寫測試用例（沒有代碼之前這些測試用例一個也通不過），然后再寫代碼讓這些測試用例通過。更進一層的講就是：編寫足夠的測試用例使測試失敗，編寫足夠的代碼是測試成功。我們編碼的目的更加明確的。
TDD是大名鼎鼎的極限編程的一個最重要的設計工具之一（另一個是重構（Refactoring），這是它的榮譽，下面我列舉幾點它實際的好處。
TDD帶來的好處有：
1、你會更加站在用戶的角度去看你將要完成的產品，你要盡可能想到用戶所有進行的操作。而不是從程序員的角度想用戶應該會如何去使用我們的產品。
2、測試用例是在對功能進行測試。在寫代碼之前先寫測試用例，可以對我們編寫代碼提供指導性的參考。防止我們漏掉一些功能。
3、它使我們對自己代碼有了信心，因為我們事先設計好的所有測試用例都Pass了。
4、如果在更改代碼后測試用例不能通過，我們可以根據不能通過的測試用例精確的定位問題，并輕而易舉的解決的這個bug。
5、哈！我們的一整套完備的測試用例在這里替我們把關（把的什么關？），我們就可以十分安全的使用極限編程的另一個最重要的工具——重構。重構改變的是代碼的內部結構，而不會改變外部接口功能。知道在做重構時測試用例是把的什么關了吧！很明顯，測試用例是保證我們在進行重構時，不會影響到代碼的外部接口功能。所以我剛剛說，我們進行的重構是十分安全的。
6、基于第5點，我們找到了重構的信心，必要時候你還可以痛痛快快的并且滿懷信心的對代碼做一場大的變革。這樣我們的代碼變得干凈了，擴展性、可以維護性以及易理解性紛至沓來。
TDD有這么多好處，但它也不是免費的午餐，它需要我們有設計完備的測試用例的能力（這項能力是長期理論與實踐的結合體），否則你將會吃了虧編寫了一大堆測試用例，卻沒測到點子上。可怕的是，你還對你“測試通過”的糟糕的代碼滿懷信心。
TDD的主旨是高效，可能這個高效不是非常高的開發速度。
通常的軟件開發過程是先寫功能，然后再寫測試。甚至有時候只進行某些方面的測試，或者有省事的就略去了某些細小功能的測試，或者是忘了對這些模塊的測試。
這些看起來對軟件影響不大，但是似乎有點過于自信了。因為我們是人，不是神，所以難免會出一些這樣或那樣的錯誤，而這些小的問題在項目整合起來以后進行排錯是非常令人頭疼的。
TDD的思想是以測試推動開發進程。因為我們在軟件開發之前，每個程序單元的功能都已經確定了。程序員在理解完整個程序需求以后，直接進行開發，有可能會因為種種原因考慮不很周全，似乎功能實現的沒有問題了，但是其中卻可能隱藏著非常可怕的Bug。TDD促使開發人員先根據程序單元的功能編寫測試代碼，就像是先建一個模型，然后向里面澆注合適功能的代碼。最后滿足所有的測試驗證了，才能正常通過測試，這個程序單元才算完成。
這樣消除了開發人員主觀性的對程序單元健壯性的評估，更客觀的驗證每一個程序單元的功能實現以及可能出現的Bug。
當然，這些操作都需要有大量的代碼支持，所以費事是在所難免的，但是這點“費事”與健壯性非常強的代碼相比，有些人還是偏向于使用TDD。
首先站在客戶方代碼的立場，可以獲得更好的api。
其次可以改善軟件質量，支持重構。
其三，大幅減少debug時間。
前期投入大，后期能大幅縮短開銷，將問題發現在最源頭
提供明確的目標
你很清楚， 一旦結束（測試通過）， 你的工作就完成了（假設你的測試寫的很好）. 測試代碼會為代碼建立一個自然的邊界， 使你把重點集中在當前任務上. 一旦測試通過， 就有確切的證據證明你的代碼能工作. 相對于人工的測試用戶界面或者比較日志文件中的結果， 在一個xUnit框架中運行自動化測試， 速度要快幾個數量級. 大多數xUnit測試的運行只需幾微秒， 而且大多數采用TDD的人都會一天運行數次測試. 在許多開發小組中， 將代碼上傳配置庫前， 必須成功地通過測試。
提供文檔
你是不是經常遇到看不懂的代碼？ 這些代碼可能沒有任何文檔說明， 而且開發代碼的人可能早就走了（或者去度假了）。 當然看到這種代碼的時間往往也很不合時宜， 可能是凌晨3點， 也可能有位副總在你旁邊大聲催促著趕快解決問題， 這樣要想花些時間來愿作者的意圖就更困難了。 我們見過一些好的單元測試文檔， 它們會指出系統要做什么。 測試就像原開發人員留下的記號， 可以展示他們的類具體是怎么工作的。
改善設計
編寫測試能改善設計。 測試有助于你從界面的角度思考， 測試框架也是代碼的客戶。 測試能讓你考慮得更簡單。 如果你確實遵循了“盡量簡單而且行之有效”的原則， 就不會寫出篇幅達幾頁的復雜算法。 要測試的代碼通常依賴性更低， 而且相互之間沒有緊密的聯系， 因為這樣測試起來更容易。 當然， 還有一個額外的作用， 修改起來也會更容易！
鼓勵重構
利用一套健壯的測試集， 你能根據需要進行重構。 你是不是經常遇到一些不知是否該修改的代碼？ 種種的顧慮讓你行動遲緩， 過于保守， 因為你不能保證所做的修改會不會破壞系統。 如果有一套好的單元測試集， 就能放心的進行重構， 同時能保證你的代碼依然簡潔。
提高速度
編寫這么多測試會不會使開發速度減慢呢？ 人們經常會以速度（或開發開銷）作為反對進行TDD和使用xUnit框架的理由。 所有的新的工具都會有學習曲線， 但是一旦開發人員適應了他們選擇的框架（通常只需要很短的時間）， 開發速度實際上會加快。 一個完備的單元測試集提供了一種方法對系統完成回歸測試， 這說明， 增加一個新特性之后， 你不必因為懷疑它會不會破壞原系統而寢食難安。
提供反饋
單元測試還有一個經常被忽略的優點， 即開發的節奏。 盡管看上去好像無關緊要， 但通過測試之后你會有一種完成任務的成就感！ 你不會成天地修改代碼而沒有任何反饋， 這種測試-代碼-測試的方法會鼓勵你動作幅度小一些 通常修改一次代碼的時間僅僅幾分鐘而已。 這樣你不會一下子看到冒出一大堆新的特性， 而只是讓代碼每次前進一小步。
TDD所帶來的好處是否被過度的夸大？
當需要進行測試時，我信守下面的經驗主義的做法：
● “先測試”還是“后測試”并不重要，只要你是在測試。
● 在你的開發過程中盡可能早的考慮測試。
● 不要讓某個框框限制了你的行動。例如，不要輕信那些人告訴你的、要寫出“盡可能簡單的能夠運行的程序”—也就是所謂的YAGNI—的話。如果你的經驗告訴你，未來你會用到這個額外的類—雖然現在用不著，你應該相信你的判斷，加上這個類。
● 記住，功能測試是真正對用戶有意義的測試。單元測試只是為你—開發者—服務的。屬于奢侈品。如果你有時間去寫單元測試，那最好了：當你的程序出現問題時，它們能幫助你省去很多時間。但如果你沒有時間，你要確保功能測試能覆蓋到你的產品里用戶所期望的所有功能點。
● 如果你沒有做驅動測試開發，不要有任何的不安。有太多的因素都能導致這種開發方法在眾多的項目和個人開發習慣中水土不服（有很多因素那些TDD極端主義者們永遠都不會提）。
TDD（ 測試驅動開發） Overview
第一篇技術博客，希望有人支持，您的關注是我的動力。。。
本文主要是基于本人的開發經驗，概敘一下TDD，也就是測試驅動開發。我比較喜歡用問題方式來寫，語言水平有限 希望讀者看得懂且有幫助
TDD這個東西 你一般用了之后會上癮：） 它可能改變你以后的編程習慣
什么是TDD
故名思意就是用測試的方法驅動開發。簡單說就是先寫測試代碼，再寫開發代碼，和傳統的方式是反的。
為什么要用TDD
用TDD的方法可以使代碼干凈（代碼重構的結果），測試覆蓋率高（先寫測試的結果），軟件做集成測試的時候一般問題會比較少。
而且你敢改人家的代碼，看到有fail的test case 證明你有改錯人家的東西，看到所有的test case都過了的話，你也很有信心說，我沒有改錯，或程序不會因為我的改動而掛掉。
什么時候TDD
TDD是在Unit Test， 也就是單元測試時用的方法。
什么地方TDD
我覺得寫任何代碼都可以用TDD吧
怎么做TDD（關鍵5步）
1、加入一個新的測試
2、運行下新加的測試，看到它失敗（因為你還沒寫功能代碼）
3、對開發代碼做很小的修改，目的就是讓新加的測試通過 （注意這里的目的）
4、運行所有的測試（test case），然后看到所有測試都通過了 （看到測試都變成綠色，一般都會小開心一下）
5、移掉重復的代碼，對代碼進行重構 （既包括功能代碼，也包括測試代碼。特別注意紅色的字串 一般會有重復，還有一些代碼可以抽出來變成公用方法，測試代碼中同樣的初始化和還原測試環境的代碼，可以放到intilize和cleanup中去）
而外還有一些步驟也是可以加入的，比方
● 在寫測試代碼前，先從需求出發，準備一個Test list （需要測到的功能的列表）。忘掉你該怎么實現，那是后面的事情
● 每測完一個就用橫線劃掉
● 如果發現有漏掉的test 就加到這個列表中（列表測完你的功能也就完成了）
TDD的好處，和不足的地方
好處
● 測試代碼都是從客戶需求出發的，不是重實現出發的。測試更關注于對外部的接口。
● 軟件的需求都被測試代碼描敘得很清楚，可以減少很多不必要的文檔（有些時候寫文檔時間比開發時間多多了， 需要一個專門寫文檔的，而且用的機會很少。這里我很喜歡敏捷開發中說的：Just enough）
● 每次都是很小的步驟，這樣你就很集中注意解決一個問題。葛優說的：步子邁大了容易扯著蛋，步子大想的就多，容易忽視些東西， 容易出錯。小而簡單就是美
● 可以優化設計。如果有做過測試驅動開發的會發現，為了更好的，更容易的做單元測試。它逼著你面向接口編程和使用一些設計模式，自然設計就靈活了，耦合性也低
缺點
● 有時候開發代碼可能只有幾行，可是測試代碼可能比真正的代碼要多很多。而且花時間想怎么測試。
● 可能不適合時間很緊的軟件開發，更適合于產品和平臺的開發
怎么學習TDD最好
我覺得最好且最快的方式就是 XP中提到的結對編程，一個有TDD經驗的坐在“后面”，指導另一個不大熟悉的人，兩人一起來完成一個類或模塊的功能
幾個關鍵點
● 記得你是做單元測試，不是集成測試，你要測得僅僅是你的類的功能，不要去測別人類的功能，一定要知道測到什么程度就好了，剩下的可能是別人需要測的
● 每次都是一小步，目的只是用最簡單的方法讓新加的test case過掉而已
● 在改/加任何功能代碼前，一定要先想是不是要改或加test case。
● 測試驅動產生的單元測試代碼是代替不了集成測試的，它還是單元測試
● 測完記得清理測試環境，還原到測試之前的樣子