1. TDD
TDD指的是Test Drive Development，很明顯的意思是測試驅動開發，也就是說我們可以從測試的角度來檢驗整個項目。大概的流程是先針對每個功能點抽象出接口代碼，然後編寫單元測試代碼，接下來實現接口，運行單元測試代碼，循環此過程，直到整個單元測試都通過。這一點和敏捷開發有類似之處。
2. 爲什麼要使用TDD
部分團隊成員無緣參與需求、規範或用戶故事的制定；
大部分乃至全部測試都是手動的，抑或根本就沒有測試；
雖然使用了自動化測試，但並未檢測出真正的問題；
編寫並執行自動化測試的時間太晚，無法給項目帶來真正的價值；
總是有更緊急的問題需要處理，沒法騰出專門用於測試的時間；
整個團隊分爲測試、開發和功能分析小組，而這些小組常常不能同步；
無法重構代碼，因爲擔心這樣做會破壞既有的功能；
維護成本高；
上市時間過長；
客戶覺得交付的產品不符合要求；
文檔從來都不是最新的；
害怕部署到生產環境，因爲結果無法預料；
常常無法部署到生產環境，因爲運行迴歸測試的時間太長；
團隊爲搞清楚某些方法或類的作用花費的時間太多。
測試驅動開發並不能神奇地解決所有這些問題，而只爲我們找到解決方案指明方向。世上沒有靈丹妙藥，但如果有什麼開發實踐能讓衆多層面的情況大不相同，那就是TDD。
3. TDD步驟
測試驅動開發是一個過程，依賴於不斷重複極短的開發週期。它基於極限編程（XP）的測試優先理念，倡導採用可高度信賴的簡單設計。驅動這個流程前行的開發週期稱爲“紅燈-綠燈-重構”。
這種流程本身很簡單，由幾個反覆進行的步驟組成：
(1) 編寫一個測試；
(2) 運行所有測試；
(3) 編寫實現代碼；
(4) 運行所有測試；
(5) 重構；
(6) 運行所有測試。
鑑於測試是在實現前編寫的，因此它應該不能通過。如果通過了，就說明測試是錯誤的：要麼它描述的功能早已存在，要麼編寫不正確。編寫測試期間處於綠燈狀態昭示着存在錯報的問題，對於這樣的測試，應將其刪除或進行重構。
4. TDD的好處
(1) 保證代碼的質量
(2) 提高開發效率
(3) 能夠更好的滿足測試
(4) 減少自測的時間
(5) 能夠成爲更好的代碼說明文檔
5. 總結
並不是所有的項目都適合TDD這種模式的，我覺得必須具備以下幾個條件。
首先，項目的需求必須足夠清晰，而且程序員對整個需求有足夠的瞭解，如果這個條件不滿足，那麼執行的過程中難免失控。當然，要達到這個目標也是需要做一定功課的，這要求我們前期的需求分析以及HLD和LLD都要做得足夠的細緻和完善。
其次，取決於項目的複雜度和依賴性，對於一個業務模型及其複雜、內部模塊之間的相互依賴性非常強的項目，採用TDD反而會得不嘗失，這會導致程序員在拆分接口和寫測試代碼的時候工作量非常大。另外，由於模塊之間的依賴性太強，我們在寫測試代碼的時候可能不採取一些橋接模式來實現，這樣勢必加大了程序員的工作量。