正如許多事情都有其兩面性一樣，測試方法也是這樣。要保證測試方法正確，最簡單、最直觀地想法就是多寫些測試用例，從更多地角度去測試，但這必然增加我們的測試成本。小步快跑要求我們頻繁進行測試，假如我們重構的週期是20分鐘，但測試卻要花掉10分鐘，那麼這樣的成本就實在太大了。假如這種測試還是開發人員手工測試，每天都有對同樣的測試反覆執行數十遍，那麼開發人員估計就要瘋掉了。
你可能立即就想到自動化測試了。是的，在許多重構的書籍中，大師們都建議我們在重構開始前，首先建立自動化測試機制。但遺憾的是，我經過多年的實踐總結出來的經驗是，這幾乎不可能實現。每次重構，我們面臨的都是乙個個遺留系統。大多數遺留系統都有一些共同的特徵：**凌亂，沒有清晰的介面；**間耦合度高，相互依賴嚴重；web層、業務層、資料訪問層往往沒有清晰的界限，**相互參雜其中。在這樣的情況下，編寫自動化測試**是幾乎不可完成的任務。當然，這裡所說的自動化測試**，是指那些基於junit編寫的自動化測試程式
舉乙個簡單的例子：假如你現在要測試乙個開票類，想編寫它的測試**。本來這個開票類並不複雜，業務也很清晰。但是在函式傳遞引數時，其中乙個引數是web容器中的request、response或session。這下麻煩了，為了測試乙個簡單的函式，我們必須啟動整個web應用，這是我們不可接受的。
隨後你可能會說了，我們為什麼非要傳遞乙個真正地request、response或session呢？我們mock乙個假的嘛！想法不錯，但你真正去嘗試mock時你會發現這也是乙個不可完成的任務。request、response或session有許多的狀態，屬性變數中又有物件，又有屬性變數。除此還有大量集合變數，集合變數裡都有什麼物件，天才知道。因此，即使你費盡千辛萬苦mock出來，也可能因某些屬性不對而使得測試失敗。
另乙個寫自動化測試程式比較忌諱的就是訪問資料庫。比如你這次執行的插入操作成功了，並不意味著下次執行就可以成功。下次執行會報「主鍵衝突」錯誤，出現這個錯誤並不是被測程式錯了，而是測試程式錯了。上次執行乙個查詢產生的結果集，不一定就是下一次執行同樣乙個查詢產生的結果。查詢結果變了，並不意味著被測程式錯了，而是測試程式不對。自動化測試程式之所以能夠自動化執行，必須要保證測試過程是可以反覆執行的，並且不論什麼時候執行都有乙個確定的結果。
總之，自動化測試不是銀彈，並不是所有**都適合自動化測試。與web容器或其它裝置驅動相關的**是不適合自動化測試的，因為我們在測試的時候不希望去啟動web容器或其它裝置。因此，我們在做自動化測試程式前，首先應當確保要測試的程式已經與web容器或其它裝置驅動相關的**充分解耦。乙個比較好的辦法就是分離出web層與bus層，web層負責從web容器中獲取資料，並打包傳遞給bus層，而bus層則完成真正需要測試的業務邏輯。
另乙個不適合自動化測試的就是要訪問資料庫的程式，因為它們執行的結果總是與資料庫狀態有關，無法獲得穩定而可以不斷復現的結果。所以，我們解決它的最好辦法就是將訪問資料庫的部分mock掉。如何mock呢？你不能mock乙個jdbc，也不能mock乙個hibernate，因為那都過於複雜了，你唯一可以做的就是將dao層mock掉。這就要求我們對系統重構的時候，要將資料庫訪問的**從業務**中脫離出來，寫入到dao層。最後，被mock的dao層**並不真正去訪問資料庫。每當客戶程式傳入乙個引數時，它首先作為測試程式去驗證這個引數是否與預期一致，然後返回乙個確定的結果。
IT 想說愛你不容易
檢查了半天，也跟蹤了伺服器端的執行日誌，沒有發現什麼問題，重啟伺服器程序，繼續跟蹤排程程序和執行程序，依舊沒有看出什麼問題，後來根據日誌中的select語句又到資料庫裡面查了一下，嘿！居然沒有資料。估計是命令解析的時候出了錯誤，看來是程式問題了，在伺服器上找到執行程序的源程式，make clean ...
ROR TDD，想說愛你不容易
tdd，也就是 test driven development 測試驅動開發，其實是一種開發方式的巨大提高。它 提出了一種新的開發方式 以測試為驅動。在此，我仍然想引用乙個曾經看過的thoughtworks的 乙個人的blog中的一句話 什麼是tdd？tdd就是把你的需求用測試給描述出來。這句話一下...
東航，想說愛你不容易
我坐東航的航班是小概率事件。自05年6月做諮詢以來，平均每月飛行12次，到現在大概有600次的飛行記錄，坐東航的航班大概有10次。在10次的記錄中，印象裡只有一次準點，因此，在我印象裡 東航準點也是小概率事件，所以,除非萬不得已，我不坐東航的航班。從今年五一到現在，今天是第三次坐東航的航班，次次晚點...