前言

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

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

相信沒有真正體驗(yàn)過單元測試好處的讀者一看到“單元測試”這幾個字，可能會出現(xiàn)以下兩種反應(yīng)之一：

由于沒有單元測試的經(jīng)驗(yàn)，因此對采用這一方法去保證軟件質(zhì)量很好奇，也迫切地想要了解這一方法在項(xiàng)目中的實(shí)施

曾經(jīng)使用單元測試但效果不好，因?yàn)樵谇度胧叫袠I(yè)，時(shí)常要跟硬件打交道，單元測試很難檢測硬件問題，所以往往一看到“單元測試”這幾個字的反應(yīng)就是“沒用”

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

01

單元測試真的“無用”？

造成“單元測試無用論”的第一個原因是，運(yùn)用這一方法的時(shí)機(jī)不恰當(dāng)。不少項(xiàng)目在一開始真正關(guān)心質(zhì)量的人很少，更談不上采用一整套的方法論去保證質(zhì)量了。產(chǎn)品在開發(fā)出來后發(fā)現(xiàn)到處存在問題，只會拆西墻補(bǔ)東墻根本就不能阻止問題一而再，再而三地出現(xiàn)。于是，開始想起單元測試。一聲令下，整個項(xiàng)目開始做單元測試。單元測試以模塊為單位，需要先把項(xiàng)目拆分出來。如果你的項(xiàng)目代碼整體耦合程度較高的話，單元測試根本無從說起，拆分的工作會讓你痛苦不已。

單元測試是一項(xiàng)耗時(shí)的工作，但管理者卻往往希望在短期內(nèi)看到效果?；蛘邌卧獪y試還沒做到位管理層就等不及了，催你馬上開始下一步的開發(fā)，結(jié)果只能是前功盡棄。正確的做法是：在項(xiàng)目的開始之初就引入單元測試。對于以前沒有部署單元測試的項(xiàng)目，先只對新增加的、相對獨(dú)立的模塊做單元測試、并逐漸覆蓋老代碼。

第二個導(dǎo)致“單元測試無用論”的原因是，方法沒有運(yùn)用到位。要保證單元測試的有效性一定要引入另一個概念--代碼覆蓋。關(guān)于代碼覆蓋，我以后會另外再寫一篇文章介紹。只有將單元測試和代碼覆蓋結(jié)合在一起，綜合使用才能保證單元測試的效果。

02

最原始的“單元測試”

這里給讀者展示一下，不使用任何單元測試框架時(shí)，是怎么做單元測試的。

下面簡單以linux內(nèi)核鏈表為例：

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

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

現(xiàn)在就以INIT_LIST_HEAD函數(shù)為例，來考慮如何為這個函數(shù)設(shè)計(jì)測試用例。INIT_LIST_HEAD函數(shù)的實(shí)現(xiàn)是如此的簡單，以至于很容易讓人覺得為它設(shè)計(jì)單元測試是多余的。但是，從單元測試的角度看，只要不存在可行性問題就不應(yīng)考慮因?yàn)楹唵味粚ζ溥M(jìn)行驗(yàn)證。而且，放棄對之進(jìn)行驗(yàn)證，以后會降低代碼覆蓋率。

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

下面我們來簡單實(shí)現(xiàn)一個INIT_LIST_HEAD函數(shù)的測試用例：

int main（int argc，char **argv）{ struct list_head list; /*避免函數(shù)沒有使用參數(shù)而引發(fā)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;}

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

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

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

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

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

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

一份嚴(yán)謹(jǐn)?shù)臏y試用例，會有大量的判定。如果一個測試程序存在100次判定，其中出現(xiàn)了3次失敗，那最終顯示一個百分比的測試通過率會比較直觀，比如可以顯示97%的測試成功了。

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

03

總結(jié)

正如很多其他技巧，比如打桌球、滑雪一樣，測試驅(qū)動開發(fā)也要花費(fèi)相當(dāng)長時(shí)間來練習(xí)。許多開發(fā)者已經(jīng)接受了這種技術(shù)，而且再也不想回到從前“后期調(diào)試式編程”的方式去了。

它會使你的代碼：

產(chǎn)生的bug更少

調(diào)試時(shí)間更短

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

責(zé)任編輯：haq