单元测试

周四下午，收到同事的一封mail，他告诉我他的业务代码中使用的一个库接口的行为与预期不同，并在mail中给出了测试代码和测试结果。而这个接口是之前由我封装实现的。 ...

记得恰好是在一个月前的今天，我发布了lcut(轻量级C语言单元测试框架)0.1.0版本 。由于发布仓促，文档没能及时跟上。在stackoverflow的一个关于单元测试的帖子 上，一位叫Craig McQueen的朋友也给出了建议：“Some documentation would be helpful. Project background and goals, a features list, advantages over existing alternatives, etc would be helpful for people who are checking it out for the first time.” 看完这个建议后心里那个汗啊！不过一想到用E文编写文档心里就有些打怵。就这样在这一个月里文档依旧没有改观:(。不过，lcut本身还是有一些进步的，这两天一直规划着为lcut增加mock的支持，今天终于将这个功能加进了lcut，并发布了lcut-0.2.0-beta版，欢迎大家试用，并提出意见和建议。 ...

上午对一段代码进行单元测试，由于需要用到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 ...

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

近两天一有空就会去看看项目代码，思考一下如何利用cmockery对项目里已有的代码进行测试。项目代码中很多被调用的接口都带有输出参数，而且在这些接口中多利用返回值指示执行成败也否，而利用输出参数返回一些关键结果，这些结果值甚至影响着后续的函数执行流程。前期研究cmockery时没有注意到cmockery是否可以设置被mock接口的输出参数的值，不过回顾了一下cmockery实现的原理，觉得cmockery是应该可以支持的。遂重新翻看了一下cmockery的manual，发现在mock_query_database中确有对输出参数的mock调用，代码如下： // Mock query database function. unsigned int mock_query_database( DatabaseConnection* const connection, const char * const query_string, void *** const results) { *results = (void**)mock(); return (unsigned int)mock(); } void test_get_customer_id_by_name(void **state) { DatabaseConnection connection = { “somedatabase.somewhere.com”, 12345678, mock_query_database }; int customer_ids = 543; will_return(mock_query_database, &customer_ids); will_return(mock_query_database, 1); assert_int_equal(get_customer_id_by_name(&connection, “john doe”), 543); } ...

这么久以来一直没有找到一款很好的支持mock测试的C语言单元测试工具包，但前不久在一网友的评论中得知：去年Google曾发布了一款c语言的轻量级单元测试framework — “cmockery”，cmcokery很小巧，对其他开源包没有依赖，对被测试代码侵入性小；它支持mock test，同样也可以支持常规的单元测试。 之前在博客中曾描述过C语言实现mock的一个思路，不过和cmockery对比起来，当时我的思路显然还处于初级阶段，而cmockery则走到了更高级，使用起来也更为简便。 还是以我上一篇文章中的代码来举例，利用cmockery来对biz.c进行mock test。 应用层被测试代码不变： /* biz.h */ #ifndef BIZ_H #define BIZ_H ...

如发现本站页面被黑，比如：挂载广告、挖矿等恶意代码，请朋友们及时联系我。十分感谢！ 商务合作请联系bigwhite.cn AT aliyun.com 欢迎使用邮件订阅我的博客 输入邮箱订阅本站，只要有新文章发布，就会第一时间发送邮件通知你哦！ ...

我所在的项目一直以C语言作为主要开发语言，与做Java以及其他新兴语言的人不同，组内的同事似乎对新鲜的东西不是那么感兴趣，也没有主动去研究新鲜事物的意愿和意识。我深为此闹心，看到外面世界中那么多美妙的工具，再也不能坐以待毙了。我一直都是有很多想法的，但是迫于自身精力有限，自己无法全身投入，以前都是交予别人去做的，但是收到的效果都不是很好。认识到这点后，我决定自己动手，丰衣足食。 ...

曾经在多篇blog中报怨过：用C语言写业务逻辑实在是让人身心忐忑不安，再加之C语言自有的"特点"，让其与"单元测试"始终若即若离，曾经尝试过写了一个轻量级C Unit Testing lib，至少目前我依旧在用，但多用在编写独立算法以及底层库的场合。业务层少有使用。业务层多是遗留系统，当初前辈们设计时对可测性考虑不够周全，导致现在无法很好的将各个部分独立抽出进行测试，虽然我们也在做着类似"重构"的工作，但鉴于规模较大，不能一蹴而就，我们需要一步一步找出使用C应对各种单元测试情况的方法。这里说说Mock Test。 ...

每天早晨都是坐公司的班车上班的，从家到公司大约需要40分钟，这段时间不短也不长。为了打发时间，也曾经想过要充分利用这段时间，我选择过听音乐、看书。但音乐听时间长了就听烦了；在车上看书时间长了还有些头晕，所以多数时间我还是选择"思考"。“思考"的同时，眼睛也一直在"欣赏"车窗外的风景。今天窗外一处新楼盘门市的两个破碎的窗户让我的"思考"有了方向。 ...