這個話題老生長談了，單元測試程式碼的用途和重要性不言而喻，但是在日常工作中，程度員總有各式各樣的理由來拒絕寫單元測試程式碼。從上個專案的親身經歷看，程式設計師不樂意寫單元測試程式碼的理由有如下幾類：

1、沒時間。專案進度太緊張，專案計劃裡完全沒有預留單元測試程式碼開發的時間；正常程式碼想搞完時間都很緊張，程式設計師巴不得把業務程式碼搞定之後休息、放鬆一下，單元測試程式碼再重要，但其開發工作也就自然放在一邊了。

2、沒必要。老程式碼一大片，都堆在那裡，身經百戰，產品應用那麼久，如果有Bug早該發現了，現在寫單元測試程式碼不是浪費時間和金錢嘛。

3、不必要。程式碼功能這麼簡單，邏輯也不復雜，抽時間程式碼Review就可以了，何必為其專門開發單元測試程式碼。

4、工具不足。如缺少打樁工具，模組之間依賴重重或者沒有依照面向介面的思想開發，導致靜態物件滿天飛，程式設計師手裡缺少簡單易用的打樁工具，導致各種業務場景無法模擬，異常場景更是不消講，單元測試的意義大打折扣，程式設計師沒有意願付出時間開發單元測試程式碼。

5、程式設計師自身能力不足。對專案組可用的單元測試工具使用不熟練，開發單元測試程式碼時間效率低下，或者需要花費很多時間解決單元測試程式碼中的問題，或者單元測試程式碼執行結果不穩定，無法起到質量看護的效果，這樣也會導致程式設計師沒有興趣和意願在專案進行過程中開發單元測試程式碼。

6、需求不穩定，導致程式碼變動大，已有的單元測試程式碼需要投入時間和精力維護，這樣也會導致程式設計師沒有興趣和意願來寫單元測試。

7、老程式碼結構混亂，可測試性比較低，開發單元測試程式碼的代價比較高，而這些程式碼已應用了相當的時間，為了寫單元測試程式碼而做針對性的修改，意義不大，投入和產出不成比例。

。。。。

        寫完上面的文字，我突然想起來一段課文，勿以善小而不為，單元測試程式碼就是日常專案開發過程中的善事。所謂前人種樹，後人乘涼，當維護程式碼的後人使用前人寫好的程式碼測試程式碼來檢驗重構之後的程式碼特性是否完備、正確時，相信後人心裡是充滿感激之情的。

        需求是商務決定的，程式設計師只能默默接受而不能改變。

工具是外部條件，在不具備的時候，強行做事確實痛苦，這時不搞單元測試情有可原，因此程式設計師也只能默默接受。

        但能力問題和態度問題是程式設計師可以搞定的。比如引入新的單元測試工具，或者優先、調整已有程式碼的結構，使單元測試程式碼在寫作時不那麼痛苦，或者學習新的單元測試技術，應用到專案中。我覺得都有希望可以逐步解決上述問題。

對於Java專案而言，只要專案進度沒有緊張到天塌下來，單元測試程式碼都是可以搞，而且覆蓋率可以提升到很高的。

這裡推薦本人最喜歡的幾個工具：

1、單元測試框架Junit，這個普及程度最高，相信應當無人不知吧。

2、打樁工具EasyMock+PowerMock，有了PowerMock，模擬各種異常場景的代價大大降低，而且不需要為了寫單元測試程式碼而調整已有的醜陋程式碼。

3、覆蓋率統計工具EclEmma，配合Eclipse使用，可以方便的檢視當前開發的單元測試程式碼對功能程式碼的驗證覆蓋率，讓單元測試程式碼開發有的放矢。

EasyMock和PowerMock目前在網上的資料非常多，官網上的資料也非常翔實，有一定Java開發經驗的程式設計師在學習、應用一段時間之後都可以快速上手，所以不再贅述二者的使用方法。