程式碼整潔之道
簡介：
本書是程式設計大師“Bob 大叔”40餘年程式設計生涯的心得體會的總結，講解要成為真正專業的程式設計師需要具備什麼樣的態度，需要遵循什麼樣的原則，需要採取什麼樣的行動。作者以自己以及身邊的同事走過的彎路、犯過的錯誤為例，意在為後來者引路，助其職業生涯邁上更高臺階。
本書適合所有程式設計師閱讀，也可供所有想成為具備職業素養的職場人士參考。
第五章 測試驅動開發（TDD）
如果連所有程式碼是否都可以正常執行都不知道，還算什麼專業人士？如果每次修改程式碼後沒有測試，如何能夠知道所有程式碼可以正常執行？如果缺乏極高覆蓋率的自動化單元測試，如何能夠做到每次修改程式碼後都對程式碼進行測試？如果不採用TDD，如何能夠獲得極高覆蓋率的自動化單元測試？
5.2 TDD的三項法則
（1）在編好失敗單元測試之前，不要寫任何產品程式碼。
（2）只要有一個單元測試失敗了，就不要再寫測試程式碼；無法透過編譯也是一種失敗情況。
（3）產品程式碼恰好能夠讓當前失敗的單元測試透過即可，不要多寫。
5.3 TDD的優勢
確定性：
如果將TDD作為一項行業紀律，那麼每天要寫上幾十個測試，每週要寫上成百上千個測試，每年寫上成千上萬個測試。任何時刻，程式碼有任何修改，都必須執行手頭有的全部測試。
任何時刻，一旦修改了工程的任何部分，只需再次執行全部的單元測試即可。如果單元測試全部透過，我差不多就可以確信我的修改沒有破壞任何東西。“差不多少確信”是有多少把握？我相當有把握，足以交付了！
降低缺陷注入率：
有不少報告和研究[3]稱TDD能夠顯著降低缺陷。從IBM到微軟，從Sabre到Symantec，一家又一家公司，一個又一個團隊，經歷過缺陷下降為原來的1/2、1/5甚至1/10的過程。這些數字不能不讓專業人士動容。
給開發人員以修改最佳化工程的勇氣：
看到糟糕程式碼時，你為什麼不修改呢？看到混亂的函式時，你的第一反應是：“真是一團糟，這個函式需要整理。”你的第二反應是：“我不會去碰它！”為什麼？因為你知道，如果去動它，就要冒破壞它的風險；而如果你破壞了它，那麼它就纏上你了。
但是如果你能確信自己的整理工作沒有破壞任何東西，那又會是怎樣一種情況呢？如果你擁有我剛才提到的那種把握，會怎樣呢？如果你只需點選一個按鈕，然後90秒內便可以確信自己的修改沒有破壞任何東西，只是讓程式碼變得更好了，那麼又會是怎樣的一種情況呢？這是TDD最強大之處。擁有一套值得信賴的測試，便可完全打消對修改程式碼的全部恐懼。當看見糟糕的程式碼時，就可以放手整理。程式碼會變得具有可塑性，你可以放心打磨出簡單而滿意的結果。
當程式設計師不再懼怕整理程式碼時，他們便會動手整理！整潔的程式碼更易於理解，更易於修改，也更易於擴充套件。程式碼更簡潔了，缺陷也更少了。整個程式碼庫也會隨之穩步改善，杜絕業界常見的放任程式碼劣化而視若不見的狀況。
單元測試就是文件：
遵循TDD三項法則的話，所編寫的每個單元測試都是一個示例，用程式碼描述系統的用法。如果遵循三項法則，那麼對於系統中的每個物件，單元測試都可以清楚描述物件的各種建立方法。對於系統中的每個函式，單元測試可以清楚描述函式的各種有意義的呼叫方式。對於需要知道的任何用法，單元測試都會提供詳盡的描述。
單元測試即是文件。它們描述了系統設計的最底層設計細節。它們清晰準確，以讀者能夠理解的語言寫成，並且形式規整可以執行。它們是最好的底層文件。
利於設計：
如果不先寫測試，就有可能出現各個函式耦合在一起最終變成無法測試的一大團的問題。如果後面再寫測試，你也許能夠測試整個大塊的輸入和輸出，但是很難測試單個函式。因此，遵循三項法則並且測試先行，便能夠產生一種驅動力，促使你做出松耦合的設計。
總結：使用測試驅動開發是專業人士的選擇；
它是一項能夠提升程式碼確定性、給程式設計師鼓勵、降低程式碼缺陷率、最佳化文件和設計的原則。對TDD的各項嘗試表明，不使用TDD就說明你可能還不夠專業。
當然，在某些場合照這三項法則去做會顯得不切實際或不合適。這種情況很少，但確實存在。如果遵循某項法則會弊大於利，專業的開發人員就當然不會選用它。