此事已有定論

TDD絕不僅僅是一種用於縮短編碼周期的簡單技巧。

每個開發人員都要適應和掌握TDD。

TDD的三項法則

1、在編好失敗單元測試之前，不要編寫任何產品代碼。

2、只要有一個單兇測試失敗了，就不要再寫測試代碼；無法通過編譯也是一種失敗情況。

3、產品代碼恰好能夠讓當前失敗的單元測試成功通過即可，不要多寫。

TDD的優勢

確定性：任何時刻，代碼有任何修改，都必須運行手頭有的全部測試。

缺陷註入率：無需更多判斷，單憑測試全部通過，便敢冒可能的風險發布代碼。TDD能夠顯著降低缺陷。

勇氣：擁有一套值得依賴的測試，便可完全打消對修改代碼的全部恐懼。

文檔：單元測試即是文檔。它們描述了系統設計的最底層設計細節。

設計：測試先行的需要，會迫使去考慮什麽是好的設計。

專業人士的選擇：它是一項能夠提升代碼確定性、給程序員鼓勵、降低代碼缺陷率、優化文檔和設計的原則。

TDD的局限

即使做到了測試先行，仍有可能寫出糟糕的代碼。因為寫出的測試代碼可能就很糟糕。

某些場合不合適TDD，這種情況很少，但確實存在。

程序員的職業素養 讀書筆記 - 第5章 測試驅動開發