正如許多事情都有其兩面性一樣，
測(cè)試方法也是這樣。要保證測(cè)試方法正確，最簡(jiǎn)單、最直觀地想法就是多寫些
測(cè)試用例，從更多地角度去測(cè)試，但這必然增加我們的測(cè)試成本。小步快跑要求我們頻繁進(jìn)行測(cè)試，假如我們重構(gòu)的周期是20分鐘，但測(cè)試卻要花掉10分鐘，那么這樣的成本就實(shí)在太大了。假如這種測(cè)試還是開發(fā)人員手工測(cè)試，每天都有對(duì)同樣的測(cè)試反復(fù)執(zhí)行數(shù)十遍，那么開發(fā)人員估計(jì)就要瘋掉了。
你可能立即就想到
自動(dòng)化測(cè)試了。是的，在許多重構(gòu)的書籍中，大師們都建議我們?cè)谥貥?gòu)開始前，首先建立自動(dòng)化測(cè)試機(jī)制。但遺憾的是，我經(jīng)過多年的實(shí)踐總結(jié)出來的經(jīng)驗(yàn)是，這幾乎不可能實(shí)現(xiàn)。每次重構(gòu)，我們面臨的都是一個(gè)個(gè)遺留系統(tǒng)。大多數(shù)遺留系統(tǒng)都有一些共同的特征：代碼凌亂，沒有清晰的接口；代碼間耦合度高，相互依賴嚴(yán)重；
web層、業(yè)務(wù)層、數(shù)據(jù)訪問層往往沒有清晰的界限，代碼相互參雜其中。在這樣的情況下，編寫自動(dòng)化測(cè)試代碼是幾乎不可完成的任務(wù)。當(dāng)然，這里所說的自動(dòng)化測(cè)試代碼，是指那些基于
JUnit編寫的自動(dòng)化測(cè)試程序
舉一個(gè)簡(jiǎn)單的例子：假如你現(xiàn)在要測(cè)試一個(gè)開票類，想編寫它的測(cè)試代碼。本來這個(gè)開票類并不復(fù)雜，業(yè)務(wù)也很清晰。但是在函數(shù)傳遞參數(shù)時(shí)，其中一個(gè)參數(shù)是Web容器中的Request、Response或Session。這下麻煩了，為了測(cè)試一個(gè)簡(jiǎn)單的函數(shù)，我們必須啟動(dòng)整個(gè)Web應(yīng)用，這是我們不可接受的。
隨后你可能會(huì)說了，我們?yōu)槭裁捶且獋鬟f一個(gè)真正地Request、Response或Session呢？我們Mock一個(gè)假的嘛！想法不錯(cuò)，但你真正去嘗試Mock時(shí)你會(huì)發(fā)現(xiàn)這也是一個(gè)不可完成的任務(wù)。Request、Response或Session有許多的狀態(tài)，屬性變量中又有對(duì)象，又有屬性變量。除此還有大量集合變量，集合變量里都有什么對(duì)象，天才知道。因此，即使你費(fèi)盡千辛萬苦Mock出來，也可能因某些屬性不對(duì)而使得測(cè)試失敗。
另一個(gè)寫自動(dòng)化測(cè)試程序比較忌諱的就是訪問
數(shù)據(jù)庫。比如你這次執(zhí)行的插入操作成功了，并不意味著下次執(zhí)行就可以成功。下次執(zhí)行會(huì)報(bào)“主鍵沖突”錯(cuò)誤，出現(xiàn)這個(gè)錯(cuò)誤并不是被測(cè)程序錯(cuò)了，而是測(cè)試程序錯(cuò)了。上次執(zhí)行一個(gè)查詢產(chǎn)生的結(jié)果集，不一定就是下一次執(zhí)行同樣一個(gè)查詢產(chǎn)生的結(jié)果。查詢結(jié)果變了，并不意味著被測(cè)程序錯(cuò)了，而是測(cè)試程序不對(duì)。自動(dòng)化測(cè)試程序之所以能夠自動(dòng)化執(zhí)行，必須要保證測(cè)試過程是可以反復(fù)執(zhí)行的，并且不論什么時(shí)候執(zhí)行都有一個(gè)確定的結(jié)果。
總之，自動(dòng)化測(cè)試不是銀彈，并不是所有代碼都適合自動(dòng)化測(cè)試。與Web容器或其它設(shè)備驅(qū)動(dòng)相關(guān)的代碼是不適合自動(dòng)化測(cè)試的，因?yàn)槲覀冊(cè)跍y(cè)試的時(shí)候不希望去啟動(dòng)Web容器或其它設(shè)備。因此，我們?cè)谧鲎詣?dòng)化測(cè)試程序前，首先應(yīng)當(dāng)確保要測(cè)試的程序已經(jīng)與Web容器或其它設(shè)備驅(qū)動(dòng)相關(guān)的代碼充分解耦。一個(gè)比較好的辦法就是分離出Web層與BUS層，Web層負(fù)責(zé)從Web容器中獲取數(shù)據(jù)，并打包傳遞給BUS層，而BUS層則完成真正需要測(cè)試的業(yè)務(wù)邏輯。
另一個(gè)不適合自動(dòng)化測(cè)試的就是要訪問數(shù)據(jù)庫的程序，因?yàn)樗鼈儓?zhí)行的結(jié)果總是與數(shù)據(jù)庫狀態(tài)有關(guān)，無法獲得穩(wěn)定而可以不斷復(fù)現(xiàn)的結(jié)果。所以，我們解決它的最好辦法就是將訪問數(shù)據(jù)庫的部分Mock掉。如何Mock呢？你不能Mock一個(gè)JDBC，也不能Mock一個(gè)Hibernate，因?yàn)槟嵌歼^于復(fù)雜了，你唯一可以做的就是將DAO層Mock掉。這就要求我們對(duì)系統(tǒng)重構(gòu)的時(shí)候，要將數(shù)據(jù)庫訪問的代碼從業(yè)務(wù)代碼中脫離出來，寫入到DAO層。最后，被Mock的DAO層代碼并不真正去訪問數(shù)據(jù)庫。每當(dāng)客戶程序傳入一個(gè)參數(shù)時(shí)，它首先作為測(cè)試程序去驗(yàn)證這個(gè)參數(shù)是否與預(yù)期一致，然后返回一個(gè)確定的結(jié)果。