《重構與模式（修訂版）》—第1章1.4節測試驅動開發和持續重構

本節書摘來自異步社群《重構與模式（修訂版）》一書中的第1章1.4節測試驅動開發和持續重構，作者【美】joshua kerievsky，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

1.4　測試驅動開發和持續重構

重構與模式（修訂版）

測試驅動開發[beck, tdd]和持續重構，是極限程式設計諸多優秀實踐中的兩個，它們徹底改進了我開發軟體的方式。我發現，這兩個實踐能夠幫助我和公司降低過度設計和設計不足的幾率，将時間用在按時地構造出高品質、功能豐富的代碼上。

通過測試驅動開發（tdd）和持續重構，我們将程式設計變成一種對話1，進而高效地使可以工作的代碼不斷演變。

問：編寫一個測試，向系統提問。

答：編寫代碼通過這個測試，回答這一提問。

提煉：通過合并概念、去蕪存菁、消除歧義，提煉你的回答。

反複：提出下一個問題，繼續進行對話。

這種程式設計節奏使我耳目一新。通過使用測試驅動開發，我們再也不用先花大量時間仔細考慮一個設計，就能夠應付系統的每個細枝末節了。現在，我可以用幾秒鐘或者幾分鐘，先讓原始的功能正确地工作起來，然後再重構，使它不斷演進，達到必需的複雜程度。

kent beck為測試驅動開發和持續重構創造了一句“咒語”：“紅、綠、重構”。其中的“紅”和“綠”是指在單元測試工具（比如junit）中編寫并運作一個測試時所看到的顔色。整個過程是下面這樣的。

(1) 紅：建立一個測試，表示代碼所要完成的任務。在編寫的代碼能夠通過測試之前，測試将失敗（顯示紅色）。

(2) 綠：編寫一些權宜代碼，先通過測試（顯示綠色）。這時，你用不着為難自己，非要給出沒有重複、簡單和清晰的設計。可以在測試通過、能夠心安理得地嘗試更好的設計之後，再逐漸朝這個目标努力。

(3) 重構：對已經通過測試的代碼，改進其設計。

聽上去就這麼簡單，測試驅動開發和持續重構使程式設計領域面目一新。那些缺乏經驗的程式員可能會這樣想：“什麼？為還不存在的代碼編寫測試？編寫的代碼通過測試之後，還需要立即進行重構？這不就是那種浪費很大、雜亂無章的軟體開發方式嗎？”

實際上，事情恰恰相反。測試驅動開發和持續重構提供了一種精益、疊代和訓練有素的程式設計風格，能夠最大程度地有張有弛，提高生産率。martin fowler稱之為“迅速而又從容不迫”[beck, tdd]，而ward cunningham則解釋說，這種說法主要指的是持續分析和設計，與測試關系不大。

程式員需要從實踐中學習測試驅動開發和持續重構的正确節奏。我認識的一位程式員tony mobley曾稱這種開發風格為一次範型轉變，其影響之巨，不亞于結構化程式設計到面向對象程式設計的轉變。無論你需要多長時間來适應這種開發風格，一旦習慣之後，你将發現，再用其他任何方式開發成品代碼，都會感覺奇怪、不舒服甚至非常業餘。許多使用測試驅動開發和持續重構程式設計的人，都發現這種方式有助于：

保持較低的缺陷數量；

大膽地進行重構；

得到更簡單、更優秀的代碼；

程式設計時沒有壓力。

要了解測試驅動開發的細節，請研讀test-driven development [beck, tdd]或者test-driven development: a practical guide [astels]兩部著作。要對測試驅動開發有感性認識，可以參見本書的7.5.3節和6.5.2節。要了解如何持續重構，請研讀《重構》[f]一書（尤其是第1章）以及本書中的重構内容。

1對話這個隐喻出自kent beck，借用了大哲學家蘇格拉底的對話教學方式。編寫測試代碼就好像是向系統提問題，編寫系統代碼是為了回答問題，這樣的對話不斷反複，最後生成的就是我們所需要的系統。——譯者注

本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。