TDD，測試驅動開發（Test Driven Development）是極限編程中倡導的程序開發方法，以其倡導先寫測試程序，然后編碼實現其功能得名。本文將對TDD有一個較為系統的認識。
起源：20世紀90年代。
性質：一種由極限編程倡導的程序開發方法。
中心思想：先寫測試程序，然后編碼實現其功能。
目的：取得快速反饋並使用“illustrate the main line”方法來構建程序。
1、戴兩頂帽子的開發方式
（1）戴實現功能的帽子,在測試的輔助下,快速實現其功能。
（2）戴上重構的帽子,在測試的保護下,通過去除冗余的代碼,提高代碼質量。
2、中心思想
測試驅動着整個開發過程。
（1）驅動代碼的設計和功能的實現。
（2）驅動代碼的再設計和重構。
1、特征
測試驅動開發是需求分析和詳細設計的范疇,在代碼基本完畢以后,並且這些測試也成為單元測試的一個部分。
2、要點
可讀性甚至比生產代碼更重要，明確，簡潔，足夠的表達力。
3、一般模式
構造數據 — 操作數據 — 檢驗數據
4、遵循的規則
（1）單個測試中斷言數量應該最小化，可以快速方便地理解其結論。
（2）每個測試一個概念，即每個測試函數只做一件事。
（3）F.I.R.S.T原則
快 速（First）：能夠快速運行。
獨 立（Independence）：可單獨運行每個測試，也就是說可以任何順序運行測試。
可重復（Repeat）：在任何環境中測試均能通過。
自動驗證（Spontaneous Verification）：應有布爾值輸出。
及 時（Timely）：應在生產代碼之前編寫。
1、在編寫不能通過的單元測試前,不可編寫生產代碼。
2、只可編寫剛好無法通過的單元測試,不能編譯也算不通過。
3、只可編寫剛好足以通過當前失敗測試的生產代碼。
總的來說就是先寫測試再寫生產代碼，寫一個測試就應該立即寫它的實現代碼。
1、正面
（1）可以有效避免過度設計帶來的浪費。
（2）可以讓開發者在開發中擁有更全面的視角。
（3）確保所有需求都能被照顧到。
2、負面
（1）過度關注用例和測試案例,而不是設計本身。
（2）可能會導致單元測試的覆蓋度不夠,比如可能缺乏邊界測試。
（3）放慢開發實際代碼的速度。
（4）對於GUI,資料庫和Web應用而言,構造單元測試比較困難,若強行構造單元測試,反而會給維護帶來額外的工作量。
（5）test case 並沒有那么好寫,如果說我們開發的Test Case是用來保證我們代碼實現的正確性，那么，誰又來保證我們的Test Case的正確性呢？
使用TDD完成過一個小游戲項目，感覺TDD的開發方式讓我覺得有了另一種思維開發方式，從這個項目的各個功能點來寫測試，並通過測試來實現我們的生產代碼。以前完成一個項目是自上而下的思維，就是站在一個宏觀的角度，來全局總覽這個項目，那么最開始的時候就得考慮很多，這個時候最容易陷入細節誤區了，即會細化到某些細節難以控制自己的思維。現在接觸TDD之后，給我的感覺就是自下而上了。不考慮全局的東西，我一個小功能一個小功能的實現，曾經是從樹頂來做，現在是從樹根了，每一個根節點實現了我往上一層一層加起來，最后就是一棵樹了，哈哈~
ps：本文內容若是有誤或者迷糊，還請指正或指出。