1、概述
測試驅動開發（Test Driven Development，簡稱TDD），距今已有20多年的歷史。簡單來說TDD就是：測試代碼優先於產品代碼編寫，通過測試不斷驅動編寫完善的產品代碼，實現所需的功能。TDD與通常開發模式在角度和思考方式上相反，會讓剛接觸TDD的人難以接受。
2、TDD所遵循的三個基本原則如下：
-
在編寫好失敗的單元測試之前，不允許編寫任何的產品代碼。
對於任何功能需求，都是先從寫測試用例入手，爲滿足測試用例才能去寫產品代碼。 -
只允許編寫剛好能夠導致失敗的單元測試。只要有一個單元測試失敗了，就不要再寫測試代碼。（無法通過編譯也是屬於一種失敗)
通常在完成產品代碼開發後寫的測試用例都是儘可能通過的測試用例，很可能因先入爲主導致不能正確覆蓋測試。相反，TDD編寫新的失敗測試用例是爲了覆蓋不同的需求，在測試的深度和捕獲錯誤的靈敏度上會更勝一籌。 -
只允許編寫剛好能夠使一個失敗的單元測試通過的產品代碼，不要多寫。
編寫的生產代碼只能是爲了使一個失敗的單元測試通過，不應編寫多餘的實現代碼。如果過多編寫了實現其他功能業務的代碼，則違反了TDD的原則。
3、測試驅動開發的基本流程：
先寫一段測試代碼，很快你會發現還缺少一些類和函數，所以單元測試無法編譯，然後再寫一些產品代碼，讓這些測試能夠編譯成功，然後再回過頭接着寫單元測試代碼。這個循環不斷反覆，測試代碼和產品代碼同步增長，互爲補充。測試代碼之於產品代碼，就猶如抗體之於抗原。
4、TDD的優勢
-
確定性
TDD模式下測試代碼的至少可以覆蓋90%的產品代碼。任何時刻，代碼有任何修改，都必須運行手頭有的全部測試。如果單元測試全部通過，那麼幾乎可以確定修改沒有破壞原有的功能，軟件足以交付。 -
缺陷注入率非常低。
-
勇氣和勇氣
看到混亂的代碼時，你的第一反應是：“真的是一團糟，這段代碼該重構了。”你的第二反應：“我不會去碰它！”因爲你知道改動舊代碼，風險很高。TDD擁有一套值得信賴的測試，可以完全打消對修改代碼的全部恐懼。當程序員不再恐懼整理、優化代碼時，系統代碼會變得越來越整潔。 -
文檔
單元測試即是文檔，它們以讀者能理解的語言寫成，清晰準確地描述了系統最底層的設計細節，形式規整可以運行，便於用戶理解系統的功能。它們是最好的系統文檔，完全可以替代接口文檔。 -
設計
測試代碼的一個問題是必須隔離出待測試的代碼。如果一個函數調用了其他函數，單獨測試它通常會比較困難。爲了編寫測試，必須找到將這個函數和其他函數解耦的辦法，換言之，TDD迫使你去考慮什麼是好的設計，促使你對代碼的抽取和解耦，利於代碼複用。