一、 單元測試概述

　　1. 1 什么是單元測試

　　單元測試，就是針對代碼單元的獨立測試。為什么需要單元測試呢？這是代碼的基本特性決定了的。代碼有一個基本特性，就是對數據分類處理。

　　代碼通常會有很多的判定。一個判定，就是一次分類。嵌套的判定，會使分類次數的翻倍。

　　如果我們在寫代碼的時候，有一個分類漏掉了，就會產生一個Bug；如果一個分類，雖然寫了代碼，但是處理不正確，也會產生一個Bug。一個函數要沒有錯誤，必須做到兩點：1，對數據的分類必須完整；2，每一個分類的處理必須正確。做到了這兩點，就可以說，代碼的功能邏輯是正確的。

　　那么，如何檢測代碼的功能邏輯是否正確呢？

　　調試，是臨時的，且不完整的，例如，一個函數有十種輸入，調試能覆蓋五六種就不錯了。而系統測試，并不針對某個具體的函數，不關注某個函數的功能邏輯是否正確。

　　要檢測某個函數的功能邏輯，就必須要依照分類列出數據，檢測代碼是否對每一個分類都做了處理，而且每一個分類的處理是否正確。

　　——這就是單元測試。

　　1. 2 單元測試的基本方法

　　由上面的分析可以看出，單元測試的基本方法就是：依數據的分類列出輸入，執行被測試程序，然后，判斷輸出是否符合預期。

　　單元測試能達到什么樣的效果呢？那就是：無論別人怎么樣，我總是對的！

　　這里的“別人”，是指關聯代碼。“我”，是指當前正在編寫或測試的代碼。單元測試要做到的是，無論關聯代碼是否有錯，都要保證我是對的。具體來說，我要考慮關聯代碼會產生什么樣的數據，這些數據要如何分類處理，只要我的分類和處理是正確的，那么，無論別人怎么樣，我總是對的。

　　1. 3 單元測試的效益

　　單元測試的效益可以說是立竿見影，并且會推動整個開發過程的改進。

　　首先，單元測試可以保證代碼的質量。因為只有單元測試，能夠全面檢測代碼單元的功能邏輯，排除代碼中大量的、細小的錯誤。

　　其次，排錯成本最小。如果在編碼階段同時進行單元測試，排錯成本可以忽略不計。但若到了后期，排錯成本可能會增長上百倍，要是產品已經到了用戶手里，那造成的損失就更難說了。

　　第三，提升開發效率。單元測試可以讓程序行為一目了然，也就是程序行為可視化。什么叫程序行為呢？就是什么輸入下，會執行哪些代碼，會產生什么輸出。如下圖，黑色的代碼是當前輸入下所執行代碼。

　　如果我們寫幾行代碼，就可以看到程序的行為，相當于寫文章時上下文可見，這可以促進我們的開發思維。如果我們的思維有了偏差，也可以及時發現。如果代碼中有了錯誤，也可以隨時排除。

　　那么，是不是整個項目的所有代碼都做了單元測試，才能得到這些效益呢？不是的。80:20規則，在軟件開發過程中也存在。也就是說，80%的代碼錯誤，可能存在于20%的代碼中；80%的編碼、調試成本，可能會消耗在20%的代碼上。這20%，就是算法密集度高的代碼，也就是功能邏輯復雜的代碼。

　　這些代碼可能只有20%，但是卻可能包含了80%的錯誤，消耗了80%的編碼、調試時間，即使只對這部分代碼進行單元測試，在提升產品的質量和開發效率方面，也會產生立竿見影的效果。

　　第四，自動回歸。如果沒有單元測試，系統測試發現了錯誤，當然要修改代碼，而修改代碼可能引入新的錯誤，又要進行全面的系統測試，這樣就可能陷入循環，這通常也是項目延期的主要原因。

　　如果有了單元測試，修改代碼時可以通過回歸測試馬上檢測是否引入了新的錯誤。所謂回歸，就是回復到原來正確的狀態。

　　正是回歸測試，使單元測試對整個開發過程的改進都產生積極影響，使項目適應頻繁變化的需求。單元測試是敏捷開發的基礎和核心，反過來說，有了單元測試，開發過程會自動趨于敏捷。單元測試也降低了后期測試的壓力。

　　二、 單元測試實踐的主要問題

　　單元測試有個特點：測試簡單獨立的代碼很容易，但要在實際工作中做好單元測試卻很困難。

　　根據我們的經驗，企業在實施單元測試時，通常會面對四大問題——

　　不愿做：程序員沒有單元測試習慣。

　　沒時間：編寫測試代碼需要耗費大量的時間，項目的周期可能不允許。

　　做不了：代碼具有較高的耦合性，使單元測試難以進行。

　　做不好：測試效果不能令人滿意。我們通常會以覆蓋率來衡量測試效果，但要實現高標準的測試覆蓋很困難。

　　三、 解決思路和方法

　　如何解決上述問題呢？接下來，談談一些思路和方法，使用的工具是Visual Unit。Visual Unit，簡稱VU，是可視化的C/C++單元測試工具。

　　3. 1 如何解決“不愿做”和“沒時間”

　　對于“不愿做”，我們采用的對策是可視化，這個可視化，是指程序行為可視，后面我會用案例來演示；對于“沒時間”，采用的對策是自動化，通過自動生成測試代碼、自動打樁等功能，讓測試的時間成本最小化。這兩者結合起來，就是ETDD開發模式。

　　那么，ETDD是什么呢？

　　首先來介紹一下TDD，TDD就是測試驅動開發，這個大家可能聽得比較多了。ETDD就是Easy TDD，即：易行版的TDD。ETDD具有以下一些特點：

　　可視化，在開發過程中，程序行為可視。

　　自動化，除了測試數據需要人工設定外，其他基本上都自動完成。

　　現實化，不一定要測試所有代碼，在開始階段，可以只測試功能邏輯復雜的20%代碼。

　　下面，我用一個案例，講解一下ETDD的過程：

　　假如我要編寫一個函數，它的功能是刪除字符串左邊的空格。

　　先寫好函數的框架，能通過編譯就行。在編寫代碼前，程序員必須要做的一件事情，是想清楚代碼的功能。如果我們想的時候，順手把它記錄下來，就可以讓代碼的功能更清晰、更明確。

　　我們現在來記錄代碼的功能。這里的記錄，不是文字形式的寵統說明，而是數據形式的精確定義，也就是用輸入和輸出的方式來記錄。

　　首先，記錄最基本的功能，也就是最基本、最常見的輸入和輸出。輸入一個左邊有空格的字符串，輸出是刪除左邊空格后的字符串，返回值跟參數的輸出是一樣的。

　　然后，記錄詳細的功能。例如，左邊沒有空格的，全是空格的，還有空字符串。

　　把每種輸入的正確輸出也記錄一下。完成了這個工作后，代碼的功能就完全定義下來了。

　　現在，我們開始編寫代碼。我的編碼思路是這樣的：分為兩步，第一步計算左邊的空格數量；第二步，將非空格的字符向左移動，覆蓋掉左邊的空格。

　　以下幾行代碼，計算左邊的空格，現在編譯一下。CTRL+F7。如果編譯通過，測試就會自動運行。

　　我們可以看到，輸入是什么，執行了哪些代碼，產生了什么輸出。這里，黑色的是當前輸入下所執行的代碼，未執行的話會顯示為紅色。這里全是黑色，表示當前輸入下執行了全部代碼。如果我們想看一下計算左邊空格的結果對不對，這是內部的數據，要指定位置后才會打印出來。按ESC鍵回到開發環境。

　　用這種語法可以輸出內部數據，適合于程序員開發過程中使用。復雜類型也可以用同樣的語法輸出。

　　另一種輸出內部數據的語法是，在左邊的代碼窗口，在要輸出的位置點擊一下，右鍵菜單選擇“輸出內部數據”，這樣填一下就行了。這種方式不會修改產品代碼，適合于測試員使用。

　　再次執行后，可以看到，左邊的空格的數量是4，這是對的，那我們可以繼續編寫。