測試驅動開發Test Driven Development,英文縮寫TDD

測試驅動開發（Test Driven Development,英文縮寫TDD）是極限編程的一個重要組成部分，它的基本思想就是在開發功能代碼以前，先編寫測試代碼。也就是說在明確要開發某個功能後，首先思考如何對這個功能進行測試，並完成測試代碼的編寫，而後編寫相關的代碼知足這些測試用例。而後循環進行添加其餘功能，直到完成所有功能的開發。代碼整潔可用(clean code that works) 是測試驅動開發所追求的目標。

測試驅動開發有不少優勢：
(1)完工時完工。代表開發人員能夠很清楚的看到本身的這段工做已經結束了，而傳統的方式很難知道何時編碼工做結束了。
(2)全面正確的認識代碼和利用代碼，而傳統的方式沒有這個機會。
(3)開發小組間下降了交流成本，提升了相互信賴程度。
(4)避免了過渡設計。
(5)系統能夠與詳盡的測試集一塊兒發佈，從而對程序的未來版本的修改和擴展提供方便。
(6)逃避了設計角色。對於一個敏捷的開發小組，每一個人都在作設計。
(7)大部分時間代碼處在高質量狀態，100％的時間裏成果是可見的。
(8)因爲能夠保證編寫測試和編寫代碼的是相同的程序員，下降了理解代碼所花費的成本。
(9)爲減小文檔和代碼之間存在的細微的差異和由這種差異所引入的Bug做出傑出貢獻。
(10)在預先設計和緊急設計之間創建一種平衡點，區分哪些設計該事先作、哪些設計該迭代時作提供了一個可靠的判斷依據。
(12)發現比傳統測試方式更多的Bug。

負面評價

1. 開發者可能只完成知足了測試的代碼，而忽略了對實際需求的實現。有實踐者認爲用結對編程的方式能夠有效的避免這個問題。
2. 會放慢開發實際代碼的速度，特別對於要求開發速度的原型開發形成不利。這裏須要考慮開發速度須要包含功能和品質兩個方面，單純的代碼速度可能不能徹底表明開發速度。
3. 對於GUI,資料庫和Web應用而言。構造單元測試比較困難，若是強行構造單元測試，反而給維護帶來額外的工做量。有開發者認爲這個是因爲設計方法，而不是開發方法形成的困難。
4. 使得開發更爲關注用例和測試案例，而不是設計自己。目前，對於這個觀點有較多的爭議。
5. 測試驅動開發會致使單元測試的覆蓋度不夠，好比可能缺少邊界測試。在實際的操做中，和非測試驅動開發同樣，當代碼完成之後仍是須要補充單元測試，提升測試的覆蓋度。

歸納起來，測試驅動開發的基本過程以下：
(1) 明確當前要完成的功能。能夠記錄成一個 TODO 列表。
(2) 快速完成針對此功能的測試用例編寫。
(3) 測試代碼編譯不經過。
(4) 編寫對應的功能代碼。
(5) 測試經過。
(6) 對代碼進行重構，並保證測試經過。
(7) 循環完成全部功能的開發。