三、程序員緣何拒絕編寫單元測試?
我們已經知道了單元測試是多么重要的。為什么程序員仍然不編寫單元測試呢?為什么程序員總是有理由拒絕編寫單元測試呢?
1、 編寫單元測試，增加了工作負擔，會延緩項目進度?
這是筆者在多次討論和調查中見到程序員拒絕編寫單元測試的最多理由�！盀榱送瓿删幋a任務，沒有足夠的時間編寫單元測試。編寫單元測試會導致不能按時完成編碼任務,推遲項目進度”。事實上真的是這樣的嗎?
軟件有著其特殊的生命周期，軟件開發也具有特殊性。
首先，我們需要提供給用戶的至少是一個能運行的產品。絕對不能是一堆不能運行的和充滿了“異味”的死代碼。只有能夠運行的，滿足客戶需求的代碼才是真正有用的代碼。這時，代碼就變成產品了。
很多程序員只注重編寫代碼的完成時間，而乎略了調試代碼，集成及修改和維護時間。
如果沒有單元測試，開發活動會是這樣情景。
以一個Web應用開發為例，流程大概如此：業務代碼編寫完成打包發布到服務器進行功能測試發現問題修改代碼再打包……如此循環。
任何一個Web程序員對于這種開發情景都不會感到陌生。往往不斷的打包、發布、功能測試的時間是代碼編寫的10倍以上。通過集成系統來發現程序的bug，我們往往很難一下子準確的定位bug產生的地方。應用服務器提供的錯誤信息對于我們來說是非常有限的。
如果為每一個類都編寫單元測試并讓每一個方法測試通過，又會是怎么樣的開發情景呢?
編寫測試代碼編寫業務代碼運行測試方法修改代碼讓測試通過所有的類都通過測試打包發布到服務器進行功能測試發現bug修改測試代碼修改業務代碼測試通過再打包……如此循環。
從上面的過程顯而易見，我們需要花費更多的編碼時間。因為需要為每一個業務類編寫測試代碼。但是，它并不會導致我們總體需要花費更多的時間。我們只是可以非常輕松的在IDE環境中運行測試方法。
在代碼尚未打包發布之前我們就已經確保了業務代碼的正確性。當我們把所有通過測試的代碼集成到應用服務器后，出現錯誤的機率要少得多。當集成測試后發現bug時,我們也總是先修改測試類。保證在集成之前所有的類都經過測試通過。這樣，功能測試的時間就成數量級的減少,所以總的花費時間要比沒有單元測試要少得多。
另外，如果沒有單元測試，會經常出現一些低級的錯誤，如拼寫錯誤、空指針異常等。就因為一個小小的拼寫錯誤而需要重新打包、發布一次。如果有單元測試，就可以避免這些低級的錯誤。
如果沒有單元測試，把代碼集成到應用服務器后再發現錯誤時，我們往往更多的是憑借自己的經驗來判斷問題出在哪里。對于沒有經驗的程序員來說只能是撞運氣了。這就像是瞎子走路一樣，兩眼一摸黑。如果每個類都有單元測試，就無需要這么痛苦了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
