許多開發者都有個習慣，常常不樂意去寫個簡單的單元測試程序來驗證自己的代碼。對自己的程序一直非常有自信，或存在僥幸心理每次運行通過后就直接扔給測試組測試了。然而每次測試組的BUG提交過來后就會發現自己的程序還存在許多沒有想到的漏洞。但是每次修改好BUG以后還是懷著僥幸心理，認為這次不會有bug了。然后又一次自信地提交，結果又敗了。因為這樣反復幾次后。開發者花在找BUG和修復BUG的這些時間加起來已經比他開發這個模塊花的時間還要多了。雖然項目經理已經預留了修改BUG和單元測試的時間。但是開發者卻習慣性地在寫好代碼后就認為任務完成了。然后等問題出來了bug改了很多次還是修復不了的時候才和項目經理說“我碰到預想不到的問題，可能要延期發布我的代碼“。如果這個項目不可延期，痛苦的加班就無法避免了。

    為什么有這么多的BUG開發者卻沒發現呢。其實開發者是人又不是機器。人非圣賢孰能無過。BUG是不可避免的，只是每次在修復一個BUG之前基本上無法知道這個BUG是哪段代碼引起。每次定位BUG可能會耗去你一個小時還是一天，這還要取決于你的水平了。但是如果你的每段核心程序都有單元測試代碼。你將不需要靠你的經驗去判斷或猜測BUG是由哪段程序引起。你只要運行你的單元測試方法。通過簡單判斷測試方法的結果就可以輕松定位BUG了。所以從表面上看，為每個單元程序都編寫測試代碼似乎是增加了工作量，但是其實這些代碼不僅為你織起了一張保護網，而且還可以幫助你快速定位錯誤從而使你大大減少修復BUG的時間。而且這還有利你的身體健康，你將不會因為找不出BUG而痛苦不已，也將不用廢寢忘食地加班了。而且項目的進度也將盡在掌握。

其實單元測試不僅能保證項目進度還能優化你的設計。有些開發者會說，寫單元測試代碼太費勁了，比寫業務代碼還麻煩?？墒侨绻麖娖乳_發者必須寫單元測試代碼的時候。聰明且又想‘偷懶’的開發人員為了將來可以更方便地編寫測試代碼。唯一的辦法就是通過優化設計，盡可能得將業務代碼設計成更容易測試的代碼。慢慢地開發者就會發現。自己設計的程序耦合度也越來越低。每個單元程序的輸入輸出，業務內容和異常情況都會盡可能變得簡單。最后發現自己的編程習慣和設計能力也越來越老練了。

其實容易測試的代碼基本上可以和設計良好的代碼劃等號。因為一個單元測試用例其實就是一個單元的最早用戶。容易使用顯然意味著良好的設計。

有著良好設計的項目一直是很注重代碼重用的。代碼重用的好處在這里就不多說了。但是要做到代碼重用首先要保證被重用的單元程序必須是個非常優秀的程序，除了良好的設計，還要有詳細的文檔。另外最重要的其實是單元測試代碼。不知道大家有沒有這樣的經歷？當大家不清楚一個API 函數如何使用而去尋找文檔的幫助時，往往會跳過大段的英文說明而去直接看文檔中提供的樣例程序，然后在自己的程序中依葫蘆畫瓢調用這個函數。那么，您有沒有意識到，被重用的代碼如果有了單元測試代碼。你的測試代碼就可以成為這個函數最好的API 了。

單元測試代碼還可以通過簡單的事務回滾功能在生產環境上做基于真實數據的測試而不用擔心會產生不必要的數據。利用這樣的測試代碼我們可以在發布程序后check 剛才的發布是否成功。以往發布的時候我們經常會碰到一種比較尷尬的情況，當我們將程序發布到正式環境上后，我們每個人心里一直還是有點后顧之憂。因為我們不能在正式環境上運行我們的程序，只能被動地等待客戶操作過后才知道發布的程序是否正常。這種情況讓我們非常被動，如果運氣好可能不出什么問題，可是一旦客戶在正式環境上發現報了個系統異常之類的錯誤或者出現錯誤數據，那就后果很嚴重了，這將影響到產品的聲譽，顯然這樣也是很沒面子事。如果我們運行過單元測試代碼，萬一有問題我們就可以主動的發現并且修改后重新發布。而其有時候就算有問題也可能是一些比較低級的錯誤，或者可能是發布問題造成。基本上很快就能解決掉！這樣我們不就高枕無憂了嗎！

    很多研究結果表明，bug發現的越晚，修改它所需要的成本就越高，因此從成本角度來看，應該盡可能早地查找和修改bug。或許有人會有異議？程序員把bug全找出來了，測試組干嘛？其實測試組進行的是集成測試，這樣的測試無法全面的考慮到每個單元被調用時用的各種輸入參數。就像一輛汽車，對每個零件進行測試是必須的。對組裝好的汽車進行測試是無法代替每個零件的單獨測試。或許對組裝好的汽車進行測試可以發現某些零部件的問題。但是這個時候發現了問題就需要把汽車拆了換零件再裝上。造成的成本可想而知。

    重視單元測試后你將會發現單元測試帶來的好處遠遠不止這些。目前java下的team 開發采用cvs(版本控制) + ant(項目管理) + junit(集成測試) 的模式時，通過對ant的配置，可以很簡單地實現測試自動化。在所有的敏捷軟件開發方法中，XP（Extreme Programming極限編程，一種輕量級的、靈巧的軟件開發方法）是目前應用最為廣泛的一種， 在 XP 中推崇的Test First Design的實現已經有了現成的開發手段：“ 用Junit寫測試代碼，寫實現代碼，運行測試，測試失敗，修改實現代碼，再運行測試，直到測試成功。以后對代碼的修改和優化，運行測試成功，則修改成功。” 等到開發者習慣了這樣的開發手段后，帶給開發者將是一種享受！