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

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

其實單元測試不僅能保證項目進度還能優(yōu)化你的設(shè)計。有些開發(fā)者會說，寫單元測試代碼太費勁了，比寫業(yè)務(wù)代碼還麻煩。可是如果強迫開發(fā)者必須寫單元測試代碼的時候。聰明且又想‘偷懶’的開發(fā)人員為了將來可以更方便地編寫測試代碼。唯一的辦法就是通過優(yōu)化設(shè)計，盡可能得將業(yè)務(wù)代碼設(shè)計成更容易測試的代碼。慢慢地開發(fā)者就會發(fā)現(xiàn)。自己設(shè)計的程序耦合度也越來越低。每個單元程序的輸入輸出，業(yè)務(wù)內(nèi)容和異常情況都會盡可能變得簡單。最后發(fā)現(xiàn)自己的編程習(xí)慣和設(shè)計能力也越來越老練了。

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

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

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

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

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