Kevlin Hnney是英國的一位獨立顧問和培訓師，其關注的范圍主要包括軟件架構、模式、開發過程和程序設計語言。在本文中他將談談如何通過單元測試提高開發效率。
單元測試只會浪費時間嗎?某些軟件專家們確實是這么想的。最近在Software Quality Insights上看到一篇文章——《單元測試真的有用嗎?》。那些認為單元測試無用的開發人員給出了如下理由：
1. 他們不了解單元測試。
2. 很難寫出優秀的單元測試。
3. 單元測試只會浪費時間、降低效率。
4. 寫單元測試需要太多時間(特別是頻繁的迭代開發)。
5. 回歸測試更有效率。
本文將重點討論后面三個問題，即單元測試與開發效率的關系。
效率 vs 人員安排
單元測試會降低效率、造成時間上的浪費嗎?這取決于所說的效率是什么，以及所說的時間對象是誰。在一個純粹編寫新代碼的周期里，寫單元測試的程序員所寫代碼可能會比不寫單元測試的少。如果所說的效率是指這個，那么單元測試確實會降低程序員的效率。
但是，我們很容易發現這種牽強的效率定義的問題所在。代碼行并不是衡量效率的標準，它只是所寫代碼的行數。從單個類到整個系統，我們可以發現很多代碼行數已經遠超出了實際所需。
我們需要的并不是更多的代碼，而是準確的代碼。單元測試可以讓我們隨時進行代碼層次上的真實性檢查，它可以告訴我們是否在開發正確的東西。所以越多的測試就意味著越少的代碼。這并不是什么壞事。開發速率(development velocity)與開發速度(development speed)的區別就在于方向。向正確的方向前進即使幾步也要好于在錯誤的方向上飛奔。
另一個錯誤的想法是開發人員大部分時間都在編寫新代碼。雖然開發人員也想專心于代碼，但是現實卻并非如此。會議(與團隊、管理人員、客戶、投資商等)、郵件、程序調試、會話、文檔制作、安裝、研究評估、幫助解決問題、跟進支持、合并版本、處理配置管理系統等都是需要考慮的。
雖然各部分所占比例根據項目與公司的不同而有所變化，但是這些都是與代碼無關的活動，而且所占時間總和要高于編寫代碼占用的時間。問題在于，如果我們把一部分編碼時間用于單元測試，那么上面這些時間有多少可以轉化為編碼時間呢?
局部優化 vs 全局優化
看清全局也很重要。下面Alfred Aho說所的關于開發AWK語言的故事頗有一些值得我們考慮的地方：
“如果再有這樣一次機會，我們在開發這種語言的時候肯定會增加嚴格的測試。我們當時是把AWK當作一種"臨時性(throw-away)"語言進行開發，所以并沒有考慮嚴格的質量控制……曾經有個人用AWK編寫了一個CAD系統。他來找我，想告訴我AWK編譯器的一個Bug。他很生氣，說我浪費了他三個星期的生命，因為他用了三個星期查找他代碼里的錯誤，結果卻發現是編譯器的問題!后來我和Brian Kernighan討論過這個問題，我們覺得應該做一些質量控制方面的工作。然后，我們針對AWK所有功能做了一次嚴格的回歸測試。從那以后，我們三人無論誰為這種語言增加新功能的時候，都要先寫一份相應的測試�！�
文章來源于領測軟件測試網 http://www.kjueaiud.com/
