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