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