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/