前言

嵌入式行业摸爬滚打这几年，遇见有规范单元测试的项目寥寥无几。归根到底，无非是公司希望快速迭代出产品，有问题等客户反馈再说。当然，也有人认为是嵌入式行业都是小而美的产品居多，没有到一定量级之前，玩不起单元测试这种配置。正如做个蛋炒饭，并不需要安排主厨、二厨一般。

不过出于对代码稳定性的追求，我认为还是应该着手了解一下单元测试的。毕竟，这是有效提高代码说服力的方式之一。

相信没有真正体验过单元测试好处的读者一看到"单元测试"这几个字，可能会出现以下两种反应之一:

• 由于没有单元测试的经验，因此对采用这一方法去保证软件质量很好奇，也迫切地想要了解这一方法在项目中的实施

• 曾经使用单元测试但效果不好，因为在嵌入式行业，时常要跟硬件打交道，单元测试很难检测硬件问题，所以往往一看到"单元测试"这几个字的反应就是"没用"

如果读者是第一种反应那很好，本文就是科普单元测试的基本要点。如果读者是第二种反应，那可能是对单元测试存在偏见，本系列文章也会介绍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更少

• 调试时间更短

• 完全可以通过提交你的单元测试案例，来证明你的项目可靠性。