許多開發者都有個習慣，常常不樂意去寫個簡單的單元測試程式來驗證自己的程式碼。對自己的程式一直非常有自信，或存在僥倖心理每次執行通過後就直接扔給測試組測試了。然而每次測試組的BUG提交過來後就會發現自己的程式還存在許多沒有想到的漏洞。但是每次修改好BUG以後還是懷著僥倖心理，認為這次不會有 bug了。然後又一次自信地提交，結果又敗了。因為這樣反覆幾次後。

開發者花在找BUG和修復BUG的這些時間加起來已經比他開發這個模組花的時間還要多了。雖然專案經理已經預留了修改BUG和單元測試的時間。但是開發者卻習慣性地在寫好程式碼後就認為任務完成了。然後等問題出來了bug改了很多次還是修復不了的時候才和專案經理說“我碰到預想不到的問題，可能要延期釋出我的程式碼“。如果這個專案不可延期，痛苦的加班就無法避免了。

為什麼有這麼多的BUG開發者卻沒發現呢。其實開發者是人又不是機器。人非聖賢孰能無過。BUG是不可避免的，只是每次在修復一個BUG之前基本上無法知道這個BUG是哪段程式碼引起。每次定位BUG可能會耗去你一個小時還是一天，這還要取決於你的水平了。

但是如果你的每段核心程式都有單元測試程式碼，你將不需要靠你的經驗去判斷或猜測BUG是由哪段程式引起，你只要執行你的單元測試方法。通過簡單判斷測試方法的結果就可以輕鬆定位BUG了。所以從表面上看，為每個單元程式都編寫測試程式碼似乎是增加了工作量，但是其實這些程式碼不僅為你織起了一張保護網，而且還可以幫助你快速定位錯誤從而使你大大減少修復BUG的時間。而且這還有利你的身體健康，你將不會因為找不出BUG而痛苦不已，也將不用廢寢忘食地加班了。而且專案的進度也將盡在掌握。

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

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

有著良好設計的專案一直是很注重程式碼重用的。要做到程式碼重用首先要保證被重用的單元程式必須是個非常優秀的程式，除了良好的設計，還要有詳細的文件。另外最重要的其實是單元測試程式碼。

單元測試程式碼還可以通過簡單的事務回滾功能在生產環境上做基於真實資料的測試而不用擔心會產生不必要的資料。利用這樣的測試程式碼我們可以在釋出程式後 check 剛才的釋出是否成功。

很多研究結果表明，bug發現的越晚，修改它所需要的成本就越高，因此從成本角度來看，應該儘可能早地查詢和修改bug。或許有人會有異議？程式設計師把bug 全找出來了，測試組幹嘛？其實測試組進行的是整合APP測試，這樣的測試無法全面的考慮到每個單元被呼叫時用的各種輸入引數。就像一輛汽車，對每個零件進行測試是必須的。對組裝好的汽車進行測試是無法代替每個零件的單獨測試。或許對組裝好的汽車進行測試可以發現某些零部件的問題。但是這個時候發現了問題就需要把汽車拆了換零件再裝上。造成的成本可想而知。