單元測試實踐的主要問題與解決(1)
本文是我在“第十屆中國系統與軟件過程改進年會廣東會場”所作演講的整理稿,主要分享單元測試的一些要點、單元測試實踐的主要問題,以及如何來解決這些問題。
一、單元測試概述
1.1 什么是單元測試
單元測試,就是針對代碼單元的獨立測試。為什么需要單元測試呢?這是代碼的基本特性決定了的。代碼有一個基本特性,就是對數據分類處理。
代碼通常會有很多的判定。一個判定,就是一次分類。嵌套的判定,會使分類次數的翻倍。
如果我們在寫代碼的時候,有一個分類漏掉了,就會產生一個Bug;如果一個分類,雖然寫了代碼,但是處理不正確,也會產生一個Bug。一個函數要沒有錯誤,必須做到兩點:1,對數據的分類必須完整;2,每一個分類的處理必須正確。做到了這兩點,就可以說,代碼的功能邏輯是正確的。
那么,如何檢測代碼的功能邏輯是否正確呢?
調試,是臨時的,且不完整的,例如,一個函數有十種輸入,調試能覆蓋五六種就不錯了。而系統測試,并不針對某個具體的函數,不關注某個函數的功能邏輯是否正確。
要檢測某個函數的功能邏輯,就必須要依照分類列出數據,檢測代碼是否對每一個分類都做了處理,而且每一個分類的處理是否正確。
——這就是單元測試。
1.2 單元測試的基本方法
由上面的分析可以看出,單元測試的基本方法就是:依數據的分類列出輸入,執行被測試程序,然后,判斷輸出是否符合預期。
單元測試能達到什么樣的效果呢?那就是:無論別人怎么樣,我總是對的!
這里的“別人”,是指關聯代碼。“我”,是指當前正在編寫或測試的代碼。單元測試要做到的是,無論關聯代碼是否有錯,都要保證我是對的。具體來說,我要考慮關聯代碼會產生什么樣的數據,這些數據要如何分類處理,只要我的分類和處理是正確的,那么,無論別人怎么樣,我總是對的。
1.3 單元測試的效益
單元測試的效益可以說是立竿見影,并且會推動整個開發過程的改進。
首先,單元測試可以保證代碼的質量。因為只有單元測試,能夠全面檢測代碼單元的功能邏輯,排除代碼中大量的、細小的錯誤。
其次,排錯成本最小。如果在編碼階段同時進行單元測試,排錯成本可以忽略不計。但若到了后期,排錯成本可能會增長上百倍,要是產品已經到了用戶手里,那造成的損失就更難說了。
第三,提升開發效率。單元測試可以讓程序行為一目了然,也就是程序行為可視化。什么叫程序行為呢?就是什么輸入下,會執行哪些代碼,會產生什么輸出。如下圖,黑色的代碼是當前輸入下所執行代碼。 如果我們寫幾行代碼,就可以看到程序的行為,相當于寫文章時上下文可見,這可以促進我們的開發思維。如果我們的思維有了偏差,也可以及時發現。如果代碼中有了錯誤,也可以隨時排除。 那么,是不是整個項目的所有代碼都做了單元測試,才能得到這些效益呢?不是的。80:20規則,在軟件開發過程中也存在。也就是說,80%的代碼錯誤,可能存在于20%的代碼中;80%的編碼、調試成本,可能會消耗在20%的代碼上。這20%,就是算法密集度高的代碼,也就是功能邏輯復雜的代碼。 這些代碼可能只有20%,但是卻可能包含了80%的錯誤,消耗了80%的編碼、調試時間,即使只對這部分代碼進行單元測試,在提升產品的質量和開發效率方面,也會產生立竿見影的效果。 第四,自動回歸。如果沒有單元測試,系統測試發現了錯誤,當然要修改代碼,而修改代碼可能引入新的錯誤,又要進行全面的系統測試,這樣就可能陷入循環,這通常也是項目延期的主要原因。 如果有了單元測試,修改代碼時可以通過回歸測試馬上檢測是否引入了新的錯誤。所謂回歸,就是回復到原來正確的狀態。 正是回歸測試,使單元測試對整個開發過程的改進都產生積極影響,使項目適應頻繁變化的需求。單元測試是敏捷開發的基礎和核心,反過來說,有了單元測試,開發過程會自動趨于敏捷。單元測試也降低了后期測試的壓力。