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所有功能做了一次嚴格的回歸測試。從那以后，我們三人無論誰為這種語言增加新功能的時候，都要先寫一份相應的測試�！�
這個故事的意義就在于它是比較早的擁護“測試先行”編程方式的實例——在實現某個功能之前先把測試寫出來，而不是只在計劃或者口頭說說。另外，這個故事也說明了如何把短期、臨時性或針對性代碼轉變為長期、穩定的方案。
不過對于我們而言，最重要的是幫助證實測試將降低效率這一謬論。這里所說不是代碼編寫人員的效率——而是用戶的效率�；蛘吒鼜V泛地說，是這個開發鏈下一個環節的人的效率。
所謂測試會“降低效率與浪費時間”，充其量也只是針對編程人員而言。而所有可能出現的問題則會堆積起來，直到下一個環節才被放大，浪費更多的時間和效率。當然，程序員可以繼續解決任何后面出現的問題，不過你還會認為這屬于“正常工作”范疇內嗎？如果人們無法把編寫單元測試看作他們正常工作的一部分，他們就可能把它當作是對正常工作的一種巨大干擾，而不是考慮如何在工作中取得一個和諧的平衡點。
解決應該解決的問題
許多局部優化實際上是對全局的掌握不夠，因為他們無法意識到更深層次的問題。這樣，他們所做的許多解決性措施就只能解決表面問題，而無法觸及問題的根本所在。如果迭代過于頻繁而無法進行單元測試，這就意味著迭代的頻率已經超出了這個團隊或機構的產能。這個產能當然包括團隊的單元測試能力。
小周期迭代的目的并不是在短時間內進行迭代，迭代的目標是減少風險，以及通過持續發布功能性完整的增量版本來提高價值、改善工作流程。如果有達不到要求的地方，那么很可能是系統中的某一部分限制了迭代頻率。如果無法解除這個限制，那么最好還是延長迭代的周期，使其更適合當前的環境，而不要“賭氣”似的強制使用這個周期。
被動式的回歸測試
為什么有人說回歸測試比單元測試更有效呢？雖然具體還要取決于回歸測試指的是什么，不過這也暗示了他們對回歸測試作用的誤解。
通過再運行一次同樣的測試，回歸測試保證了對代碼所做的任何改動并沒有影響到先前測試過的行為。但是新功能呢？按照定義，你不能用回歸測試確定新功能的行為或者新功能可以實現預期的行為。所以關鍵就是要明白“回歸”這個詞。
回歸測試并不是一種僅僅與單元測試不同粒度的測試，它表示的是一種預期的測試結果�；貧w測試可以在單元、系統或者之間的任何層次上進行。它的意義在于保證不應改變的部分沒有被改變。而新測試則是要保證發生改變的部分已經根據預期產生了相應的效果。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
