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

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

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

其實(shí)容易測(cè)試的代碼基本上可以和設(shè)計(jì)良好的代碼劃等號(hào)。因?yàn)橐粋€(gè)單元測(cè)試用例其實(shí)就是一個(gè)單元的最早用戶(hù)。容易使用顯然意味著良好的設(shè)計(jì)。

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

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

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

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