前言

嵌入式行業摸爬滾打這幾年，單元遇見有規范單元測試的項目寥寥無幾。歸根到底，無非是公司希望快速迭代出產品，有問題等客戶反饋再說。當然，也有人認為是嵌入式行業都是小而美的產品居多，沒有到一定量級之前，玩不起單元測試這種配置。正如做個蛋炒飯，并不需要安排主廚、二廚一般。

不過出于對代碼穩定性的追求，我認為還是應該著手了解一下單元測試的。畢竟，這是有效提高代碼說服力的方式之一。

相信沒有真正體驗過單元測試好處的讀者一看到"單元測試"這幾個字，可能會出現以下兩種反應之一:

• 由于沒有單元測試的經驗，因此對采用這一方法去保證軟件質量很好奇，也迫切地想要了解這一方法在項目中的實施

• 曾經使用單元測試但效果不好，因為在嵌入式行業，時常要跟硬件打交道，單元測試很難檢測硬件問題，所以往往一看到"單元測試"這幾個字的反應就是"沒用"

如果讀者是第一種反應那很好，本文就是科普單元測試的基本要點。如果讀者是第二種反應，那可能是對單元測試存在偏見，本系列文章也會介紹mock測試、錯誤注入等方式，使單元測試也能合理使用于嵌入式行業。

struct list_head { struct list_head *next, *prev;};/*定義一個結構體，只含有表示前驅和后繼的指針，它就是我們的主角了*/#define LIST_HEAD_INIT(name) {  &(name), &(name) }/*靜態初始化*/#define LIST_HEAD(name) \struct list_head name = LIST_HEAD_INIT(name)/*動態初始化*/static inline void INIT_LIST_HEAD(struct list_head *list){ list->next = list;list->prev = list;}/*插入操作*//*刪除操作*//*合并操作*/...

完整代碼很長，這里沒有必要全部貼出，能起演示作用就足夠了。

現在就以INIT_LIST_HEAD函數為例，來考慮如何為這個函數設計測試用例。INIT_LIST_HEAD函數的實現是如此的簡單，以至于很容易讓人覺得為它設計單元測試是多余的。但是，從單元測試的角度看，只要不存在可行性問題就不應考慮因為簡單而不對其進行驗證。而且，放棄對之進行驗證，以后會降低代碼覆蓋率。

做單元測試需要通過編寫程序的方式來完成，所編寫的用于測試的代碼又稱為單元測試用例。

下面我們來簡單實現一個INIT_LIST_HEAD函數的測試用例:

int main(int argc,char **argv){ struct list_head list;
/*避免函數沒有使用參數而引發waining*/UNUSED(argc);UNUSED(argv);
list.prev = (struct list_head*)0xaaaa;list.next = (struct list_head*)0xbbbb;
INIT_LIST_HEAD(list);
/*檢查前指針*/if(list.prev != list){ return -1;}
/*檢查后指針*/if(list.next != list){ return -1;}
return 0;}

這應該是史上最簡單的測試用例，功能非常簡單，首先是故意將list結構體中的各個指針變量初始化為一個隨機值。然后在調用完INIT_LIST_HEAD函數之后，檢查各成員是否被初始化為了list，以判斷INIT_LIST_HEAD函數是否正常工作了。注意:這個測試程序還有一個約定，返回-1代表測試失敗，返回0表示測試成功。

這個測試用例是基于我們對INIT_LIST_HEAD函數有足夠的了解之后編寫的，這種測試方法在軟件測試領域有個正兒八經的名字，叫白盒測試。

相信通過這個NIT_LIST_HEAD函數的測試用例，你已經初步建立起了對單元測試的印象。但是千萬不要以為單元測試僅此而已，這是我刻意簡化的結果。要完整地掌握單元測試，還要好好學習一段時間。

目前，對于這個小小的單元測試案例，還有很多的不足，下面簡單羅列了幾項：

• 如果對于每一次檢查都采取直接寫if語句的形式，將造成大量的冗余代碼，并且測試用例的編寫效率也會很低。

• 通過觀察程序是否返回0或者是-1的方式來判斷所有的測試是否通過并不直觀，一旦出錯也無法馬上判斷是那一步測試出了問題。毫無疑問，我們需要更加直觀的方式來展示哪一步成功或者哪一步失敗。

• 一份嚴謹的測試用例，會有大量的判定。如果一個測試程序存在100次判定，其中出現了3次失敗，那最終顯示一個百分比的測試通過率會比較直觀，比如可以顯示97%的測試成功了。

后面會進一步介紹如何自己搭建一個簡單實用的單元測試框架，來解決上面這些問題。也會陸續展開介紹mock方法、打樁、錯誤注入、代碼覆蓋、動態分析、靜態分析、性能優化等內容。

正如很多其他技巧，比如打桌球、滑雪一樣，測試驅動開發也要花費相當長時間來練習。許多開發者已經接受了這種技術，而且再也不想回到從前“后期調試式編程”的方式去了。

它會使你的代碼：

• ?產生的bug更少

• 調試時間更短

• 完全可以通過提交你的單元測試案例，來證明你的項目可靠性。