免費午餐——先寫單元測試

        免費午餐——先寫單元測試 單元測試方法

　　前些天看見有朋友的MSN簽名檔寫著“unit testing”，就問了一下他們的單元測試是怎么做的?？磥硭麄儧]有真正做起來，只是小范圍的試一試。

　　一方面，他們沒有cruise control之類的工具，甚至連daily build都不見得有，單元測試也不上傳到版本控制里。這樣做測試的意義就不大了。

　　另一方面，他好像把單元測試和接收測試(aclearcase/" target="_blank" >cceptance testing)、集成測試(integration testing)搞混淆了。因為他說，業務邏輯很復雜，測試數據不好做……

　　單元測試，顧名思義，就是對一個單元的測試(好像什么也沒說)。通常這個單元是指(類的成員)函數，或者函數的一個功能。

　　每個測試就只針對一點，不涉及其余，還是比較好寫的。函數的輸入是什么，(對象當時的狀態是什么)，得到的輸出是什么;有幾種不同的情況……

　　我感覺，同一個函數的單元測試加在一起，就相當于這個函數的詳細設計文檔。自然，設計文檔應該在實現之前寫，而不是實現了以后再補。

　　和傳統開發方法里的詳細設計不同，寫一個單元測試，就寫一段代碼讓它通過。這樣你就不需要在實現的時候，再去讀文檔，再去回憶當時是怎么想的，能提高效率;更重要的是，這個“文檔”是能反復運行的，可以保證和實現的一致性。

　　如果你的開發環境配置的好，照我的經驗，寫單元測試再寫代碼，和直接寫代碼相比，不會多花什么時間。

　　編碼過程中有相當一部分時間是花在想清楚下一步要做什么上，想到了就把它寫成一個測試。這么做是要花一點點時間，不過能幫你盡快驗證下面的實現跟你現在想的一致;能幫你理清思路，到底有幾種情況需要考慮，就寫幾個測試;能讓函數的功能更明確，只有功能明確，才能明確的測試;能讓你的接口更合理，因為不合理的話，依賴關系太多或者接口太復雜，測試寫起來會很麻煩……

　　最重要的是，以后你改了什么東西，破壞了現在的接口，可以馬上知道。不會在發版本的最后一天，才有人告訴你：“這個功能以前是好的，我們已經好幾天沒有重新測試了?，F在壞了，不知道問題在哪里。全體加班吧!”軟件測試

　　不花什么時間，還有不少好處。免費午餐，為什么不試試呢?

原文轉自：http://www.kjueaiud.com