标签 Unittest 下的文章

从mock malloc说起

上午对一段代码进行单元测试,由于需要用到mock,所以选择使用cmockery
作为Unit Testing框架(lcut还未提供mock功能)。测试代码里需要mock malloc以模拟分配内存失败的异常情况。

编写一个用例后,Build,提示出错:multiple definition of `malloc'。经检查发现Makefile中定义mock malloc的那个目标文件(.o文件)居然被link了两次,类似于下面的这种错误情形:
$ gcc testmain.c malloc.o malloc.o
malloc.o: In function `malloc':
malloc.c:(.text+0×0): multiple definition of `malloc'
malloc.o:malloc.c:(.text+0×0): first defined here
collect2: ld returned 1 exit status

去掉一个显式链接的malloc.o文件后Build顺利通过,运行该单元测试,程序dump core,对此很是疑惑!使用gdb查看core文件,很快发现了问题所在:因为cmockery本身也使用了malloc,但在链接过程中,cmockery库中的malloc符号被绑定到了malloc.c中的那个malloc实现上了,而我们mock的那个malloc在测试用例中又被设置返回NULL,这样非法地址访问就不足为奇了。

对以上两个问题的理解或多或少都需要一些链接方面的知识,这里你可能会问到以下两个问题:
1、C运行库(libc.a)是要被作为默认库隐式提供给ld程序做链接的,那么用自己实现的malloc替代C标准库中的malloc,链接器在链接时为什么没有检查出重定义?
2、cmockery库中的malloc是如何绑定到我们自己实现的那个malloc上的呢?为什么不绑定到C运行库中的那个malloc?

从问题内容我们也似乎可隐约推论出一点:那就是链接器对目标文件(.o)和归档文件(.a)的对待似乎是不同的。没错,的确是这样的。

可执行程序是由一系列.o文件“合并”而成。以静态链接为例,.o文件集合中除了包含我们显式(.c->.o)提供的.o文件外,还有从归档文件(.a)中提取出来的.o文件。这类.o文件是“按需”从.a中提取出来的,这也符合.a文件最初设计的初衷(减少可执行文件的size + 减少可执行文件load到内存后的内存占用)。

我们用一个的例子来解释.o文件“按需”从.a中提取的过程,也顺便回答上面的两个问题。
我们有三个源文件testmain.c、print.c和libprint.c,三个文件都很简单:
/* testmain.c */
extern void print();

int main() {
    print();
    return 0;
}

/* print.c */
#include
void print() {
    printf("print in object files\n");
}

/* libprint.c */
#include
void print() {
    printf("print in archive files\n");
}
我们将libprint.c构建为一个.a文件(gcc -c libprint.c; ar rcs libprint.a libprint.o),用于模拟库中的符号。print.c中的print则是我们自定义函数,试图用来替换库中同名函数。

执行gcc testmain.c print.c -L ./ -lprint,编译顺利通过。执行a.out,输出“print in object files”。显然testmain.c中的print调用被绑定到print.o中的print函数了。分析这个编译链接过程,我们就能回答上面的两个问题了。

我们知道gcc只是一组gnu compile tools的外部名称,gcc像个指挥官,协调一系列tools去完成任务。其中链接是最后一环,ld的输入是.o文件和.a文件。以这个例子来说,最后一步执行的是ld testmain.o print.o -L ./ -lprint …..,其中…..代表的是默认传入的C运行库。链接器从左向右扫描命令行参数中的.o和.a,目的是确定最终.o集合以及为每个.o中的外部符号(引用了但是未在本.o文件中定义)确定具体定义的位置。

链接器依从左到右顺序首先扫描testmain.o,将testmain.o加入到"最终.o文件集合"(初始该集合为空),并发现testmain.o中引用了符号print,但却未定义,将该符号放到"undefined集合"中(初始"undefined集合"为空),另外testmain中还有一个符号main,与print不同,该符号为已定义的符号,同样链接器将之放到"defined集合"中(初始"defined集合"为空)。

继续从左向右扫描,轮到print.o这个目标文件了。该文件中有一个已定义的符号print和一个引用但未定义的外部符号printf,链接器的处理过程是:发现print是当前"undefined集合"中的元素,将print从"undefined集合"中取出,放入"defined集合"中; printf因无法确定定义,放入"undefined集合",print.o放入"最终.o文件集合"。

继续向右扫描,遇到libprint.a。上面说过链接器对待.a与.o不同,.a中的符号是按需提取,这里的“按需”指的就是"undefined集合"中的符号。当前"undefined集合"中只有一个元素:printf,链接器尝试在libprint.a中查找printf的定义,未果。则链接器略过libprint.a,继续向右扫描。

最后剩下的就是libc.a了,也就是默认传递的C运行库。libc.a中包含了成百上千个.o文件。但目前只剩下printf一个符号没有得到定义了,我们只需要libc.a中包含printf符号定义的那个.o文件,也就是print.o,链接器找到print.o后将print.o放入"最终.o文件集合",将printf符号从"undefined集合"挪到"defined集合"中,此致"undefined集合"变为空集合了。也就说明这次链接是成功的。

相信上面的两个问题通过这段过程描述已经可以被解释了。

如果我们将构建语句写为:gcc testmain.c -L./ -lprint print.c会发生什么呢?我们看看执行结果:
/tmp/ccSNKvLP.o: In function `print':
print.c:(.text+0×0): multiple definition of `print'
.//libprint.a(libprint.o):libprint.c:(.text+0×0): first defined here
collect2: ld returned 1 exit status

出现重定义错误!不过有了之前的基础,这里的重定义也很好理解了。gcc testmain.c -L./ -lprint print.c执行到最后一步是ld testmain.o -L./ -lprint print.o ….; 链接器扫描完libprint.a后,print的符号已经从libprint.a中的libprint.o目标文件中被"按需"提取出来放入"defined集合"中了。接下来链接器扫描print.o居然又发现了一个名为print的全局定义的符号,与"defined集合"中冲突,ld自然就会报错。

我们再来做点修改,构造一个稍微复杂些的例子:
/* testmain.c */
extern void do_print();

int main() {
    do_print();
    return 0;
}

/* print.c */
#include
void print() {
    printf("print in object files\n");
}

/* libprint.c */
#include
void print();
void do_print() {
    print();
}

void print() {
    printf("print in archive files\n");
}
在testmain.c中我们换作调用do_print了,do_print在libprint.a中有定义。执行gcc testmain.c print.c -L ./ -lprint,结果出错:
.//libprint.a(libprint.o): In function `print':
libprint.c:(.text+0xd): multiple definition of `print'
/tmp/ccoWjHZS.o:print.c:(.text+0×0): first defined here
collect2: ld returned 1 exit status

这回怎么又变成“重定义”了呢?我们来分析一下:
*扫描testmain.o,"undefined集合"中有了符号do_print;
*扫描print.o,"undefined集合"未变,"defined集合"中增加了print
*碰到libprint.a,按照"按需"提取的原则,我们找到了do_print定义,"undefined集合"中的do_print被移到"defined集合",libprint.a中的libprint.o被放置到"最终.o文件集合"中;与前面例子不同的是libprint.o中有两个符号do_print和print,作为"最终.o文件集合"中的一分子,libprint.o的地位与testmain.o和print.o是一致的,链接器需要扫描其全部内容,而不仅仅只是提取do_print,这样链接器又发现一个print的定义,与"defined集合"中的print符号重复,链接器报错!

如果要进一步了解链接器相关内容的话,推荐阅读一下下面几本书籍:
1、《链接器与加载器
2、《深入理解计算机系统
3、国人总结性质的大作《程序员的自我修养–链接、装载与库

发布一款轻量级C语言单元测试框架

基于各种xUnit框架的单元测试早已不是什么新鲜玩意儿,不过在"古老"的C语言领域,还尚未有哪种框架可以成为“寡头”。

记得2005年末的时候,初出茅庐的我吸取xUnit的设计思想在业余时间编写了一个轻量级的C单元测试框架lcut(Lightweight C Unit Test framework),当时还写了一篇文章《C单元测试包设计与实现》记录了最初的设计和实现思路。本打算将这个小工具在部门内至少是项目内推广,可无奈当时部门内部尚未认识到使用框架工具进行单元测试的好处,或者尚未形成此种技术风气,当时的我也是“人轻言微”,因此这个小工具也没能吸引足够的眼球。这么长时间以来,都是我自己一直在使用,
其间,lcut做了两次小规模修改。特别是最后一次修改,通过增加测试用例执行的返回状态(增加LCUT_TEST_RESULT()宏),让lcut可以与一些持续集成工具(如cruisecontrol.rb)结合在一起使用。

随着部门同事对单元测试认识度的提升,基于框架的单元测试也逐渐在组内执行开来,有人使用cmockery,有人使用CuTest,也有一些新同事参考以前我编写的代码开始使用lcut。中秋假期在家读完《The Passionate Programmer》(中文版名为:《我编程,我快乐-程序员职业规划之道》)后,颇有感触。这几天突然就有了把lcut发布出去的想法(咱不能总享用,不付出吧^_^)。

发布出去前的准备工作还是蛮多的:
* 挑选一个合适的开源项目托管平台
以前是sourceforge一家独大,现在则有许多选择,主流的平台包括Google code、githublaunchpad等,最终我选择了Google Code,其实也没有什么具体理由,只是因为一直都使用Google的产品,惯性使然。如果你之前已经拥有了Google的account,那么使用Google code就更加方便了。具体如何操作,Google Code有详细的官方manual供你查阅。

* "美化"和包装代码
发布出去之前,需要先对lcut代码进行一下"美化",毕竟在家里显摆和在大庭广众下展示是有不同的。代码的格式最好能适应大多数人(或者是编辑器)的口味(比如将TAB换成空格),可利用类似astyle这样的代码格式化工具按照配置号的规则对代码做一次全量格式化。另外由于要应对不同平台、不同OS,我们还要考虑代码的可移植问题,这方面我采用autoconf和automake重新编写了lcut的构建脚本。

* 测试
为了保证发布出去的包可用且是正确的,当然需要做测试了。构建测试、安装测试以及包本身的功能测试,这个还是很耗费精力的。lcut在Ubuntu 10.04(x86 32bit)和Solaris 10(x86 and Sparc)平台下都测试通过。

* 文档
头疼!lcut本身就没什么文档,另外考虑到一般对外发布都使用English编写文档,我就更纠结了。在目前发布的lcut-0.1.0版本中,文档确是欠缺的。要知lcut是如何使用的,可参考我上面提到的《C单元测试包设计与实现》或看src/example下的例子。

* Roadmap
lcut尽可能做到不是“发布后不管”,所以还要有Roadmap或是TODO计划。这里想到两点:一是补文档; 二是打算为lcut增加mock功能。

明天就是国庆了,这里将lcut(http://code.google.com/p/lcut/)发布出来权当国庆献礼了,欢迎大家试用并提出宝贵意见和建议。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats