第二部分 實踐
第六章 測試驅動設計
單元測試是一項提升代碼質量的極佳實踐 。經過測試的代碼能更好地保證編碼的意圖和實際結果相符。測試驅動開發,因為堅持先寫測試后寫代碼的方式,帶來了更多的好處。當把軟件工程和其他的工程科學進行比較的時候(我需要一些隱喻的表達)他們之間的重要差異就會顯現。
嚴格遵守TDD(測試驅動開發)的方式還回帶來非常多的好處!TDD建立了一種消費意識:當你編寫一個單元測試的時候,其實你正在創建待開發代碼的第一個消費者。這讓你思考,在測試之外,我們會如何使用這個類。
很多開發人員都有這樣的經歷:在寫一個大類的過程中,一路伴隨著很多的假設或者臆斷。然而當你真的開始使用這個類時,你才認識到一些假設是錯誤的。然后,你只好去重構代碼。TDD要求你在寫代碼之前先創建它的第一個消費者,這會讓你去思考其他代碼最終會如何使用這些待開發的代碼。
恩,從自己經手的幾個項目來看,單元測試的確都是非常非常重要的。首先你需要保證的是你寫的是100%正確的。。(這雖然不太可能)但起碼當用戶需求不變的時候,你的這個是正確的。把寫代碼和測試代碼搞成一個螺旋開發的事實。。不斷調整進度。。其實這樣子才是最省時省力的方法。
對設計的影響。TDD通過以下形式,來改進代碼的設計:
1 它幫你養成了很好的代碼“消費意識”,因為在開始寫代碼之前,就需要創建第一個消費者。
2 保持對及其簡單的一些情況進行測試(以及持續不斷地測試),能在你不小心把至關重要的基礎設施破壞了之后及時的發出警告。
3 對邊界情況的測試是必不可少的。那些難以被測試的代碼,可以把它們重構得更加簡單,而如果真的無法簡化他們的話,也應該想辦法嚴格測試它們,不管多么困難。因為復雜的事情更需要測試
4 永遠保持把測試作為構建過程的一部分。軟件中最奇怪的事情,莫過于在修改一塊完全不相關的代碼時,不小心出發的“副作用”。有了單元測試這張安全網,確實能替你節省很多的時間和力氣。
5 有一套健壯的單元測試,允許你進行一些異想天開的重構游戲(進行大量的修改,然后運行測試來看看這些修改所帶來的影響)。記得第一次和一些已經習慣于單元測試的開發人員一起動手修改代碼時,我也是非常緊張,因為大量的修改往往會破壞很多東西,但他們看起來絲毫沒有猶豫。逐漸地,我也放下心來,因為我慢慢的認識到:有了測試的保證,完全可以發信大膽地去修改代碼。
以上幾條,的確是金玉良言??!往往開發的成敗與否,都在如此細節與習慣當中。