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

    為什么有這么多的BUG開發(fā)者卻沒發(fā)現(xiàn)呢。其實(shí)開發(fā)者是人又不是機(jī)器。人非圣賢孰能無過。BUG是不可避免的，只是每次在修復(fù)一個(gè)BUG之前基本上無法知道這個(gè)BUG是哪段代碼引起。每次定位BUG可能會(huì)耗去你一個(gè)小時(shí)還是一天，這還要取決于你的水平了。但是如果你的每段核心程序都有單元測(cè)試代碼。你將不需要靠你的經(jīng)驗(yàn)去判斷或猜測(cè)BUG是由哪段程序引起。你只要運(yùn)行你的單元測(cè)試方法。通過簡(jiǎn)單判斷測(cè)試方法的結(jié)果就可以輕松定位BUG了。所以從表面上看，為每個(gè)單元程序都編寫測(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ì)。有些開發(fā)者會(huì)說，寫單元測(cè)試代碼太費(fèi)勁了，比寫業(yè)務(wù)代碼還麻煩。可是如果強(qiáng)迫開發(fā)者必須寫單元測(cè)試代碼的時(shí)候。聰明且又想‘偷懶’的開發(fā)人員為了將來可以更方便地編寫測(cè)試代碼。唯一的辦法就是通過優(yōu)化設(shè)計(jì)，盡可能得將業(yè)務(wù)代碼設(shè)計(jì)成更容易測(cè)試的代碼。慢慢地開發(fā)者就會(huì)發(fā)現(xiàn)。自己設(shè)計(jì)的程序耦合度也越來越低。每個(gè)單元程序的輸入輸出，業(yè)務(wù)內(nèi)容和異常情況都會(huì)盡可能變得簡(jiǎn)單。最后發(fā)現(xiàn)自己的編程習(xí)慣和設(shè)計(jì)能力也越來越老練了。

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

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

單元測(cè)試代碼還可以通過簡(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àn)槲覀儾荒茉谡江h(huán)境上運(yùn)行我們的程序，只能被動(dòng)地等待客戶操作過后才知道發(fā)布的程序是否正常。這種情況讓我們非常被動(dòng)，如果運(yùn)氣好可能不出什么問題，可是一旦客戶在正式環(huán)境上發(fā)現(xiàn)報(bào)了個(gè)系統(tǒng)異常之類的錯(cuò)誤或者出現(xiàn)錯(cuò)誤數(shù)據(jù)，那就后果很嚴(yán)重了，這將影響到產(chǎn)品的聲譽(yù)，顯然這樣也是很沒面子事。如果我們運(yùn)行過單元測(cè)試代碼，萬一有問題我們就可以主動(dòng)的發(fā)現(xiàn)并且修改后重新發(fā)布。而其有時(shí)候就算有問題也可能是一些比較低級(jí)的錯(cuò)誤，或者可能是發(fā)布問題造成?；旧虾芸炀湍芙鉀Q掉！這樣我們不就高枕無憂了嗎！

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

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