前些天看見有朋友的MSN簽名檔寫着“unit testing”，就問了一下他們的單元測試是怎麼做的。看來他們沒有真正做起來，只是小範圍的試一試。
一方面，他們沒有cruise control之類的工具，甚至連daily build都不見得有，單元測試也不上傳到版本控制裏。這樣做測試的意義就不大了。
另一方面，他好像把單元測試和接收測試（acceptance testing)、集成測試（integration testing）搞混淆了。因爲他說，業務邏輯很複雜，測試數據不好做……
單元測試，顧名思義，就是對一個單元的測試（好像什麼也沒說）。通常這個單元是指（類的成員）函數，或者函數的一個功能。
每個測試就只針對一點，不涉及其餘，還是比較好寫的。函數的輸入是什麼，（對象當時的狀態是什麼），得到的輸出是什麼；有幾種不同的情況……
我感覺，同一個函數的單元測試加在一起，就相當於這個函數的詳細設計文檔。自然，設計文檔應該在實現之前寫，而不是實現了以後再補。
和傳統開發方法裏的詳細設計不同，寫一個單元測試，就寫一段代碼讓它通過。這樣你就不需要在實現的時候，再去讀文檔，再去回憶當時是怎麼想的，能提高效率；更重要的是，這個“文檔”是能反覆運行的，可以保證和實現的一致性。
如果你的開發環境配置的好，照我的經驗，寫單元測試再寫代碼，和直接寫代碼相比，不會多花什麼時間。
單元測試工具
編碼過程中有相當一部分時間是花在想清楚下一步要做什麼上，想到了就把它寫成一個測試。這麼做是要花一點點時間，不過能幫你儘快驗證下面的實現跟你現在想的一致；能幫你理清思路，到底有幾種情況需要考慮，就寫幾個測試；能讓函數的功能更明確，只有功能明確，才能明確的測試；能讓你的接口更合理，因爲不合理的話，依賴關係太多或者接口太複雜，測試寫起來會很麻煩……
最重要的是，以後你改了什麼東西，破壞了現在的接口，可以馬上知道。不會在發版本的最後一天，纔有人告訴你：“這個功能以前是好的，我們已經好幾天沒有重新測試了。現在壞了，不知道問題在哪裏。全體加班吧！” 。
繼續： http://www.51qa.net/Default.aspx
