单元测试 | Tony Bai

九月 30, 2010

基于各种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、github、launchpad等，最终我选择了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/)发布出来权当国庆献礼了，欢迎大家试用并提出宝贵意见和建议。

cmockery支持mock输出参数

八月 26, 2009

0 条评论

近两天一有空就会去看看项目代码，思考一下如何利用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);
}

上面代码在test_get_customer_id_by_name中两次针对被mock的接口mock_query_database调用will_return，实际上是在符号“mock_query_database”对应的value list里插入了两个item，第一个item的值为&customer_ids，第二个为1。当测试执行到mock_query_database的第一个mock时，返回第一个item：&customer_ids，执行到第二个mock时返回第二个item的值1。这样在测试过程中设置输出参数值的目的就达到了。

在使用cmockery时唯一需要你关注的就是will_return设置的顺序和在被mock接口中调用mock的顺序，切记不要弄反了。

这里再举一个例子，再直观感受一下：

/* message_handler.c */

#include

extern int dispatch_message(void *msg);
extern int get_next_message(void **msg);

int handle_next_message() {
void * temp_msg = NULL;
int rv = 0;

        rv = get_next_message(&temp_msg);
        if (!rv) {
                if (!temp_msg) {
                        return -1;
                } else {
                        return dispatch_message(temp_msg);
                }

}

return rv;
}

/* test_message_handler.c */
#include
#include
#include
#include "cmockery.h"
#include

int dispatch_message(void *msg) {
return 0;
}

int get_next_message(void **msg) {
(*msg) = (void*)mock();
return (int)mock();
}

extern int handle_next_message();

void test_handle_next_message_success(void **state) {
        will_return(get_next_message, 0×1234);
        will_return(get_next_message, 0);
        assert_true(handle_next_message() == 0);
}

void test_handle_next_message_fail(void **state) {
        will_return(get_next_message, NULL);
        will_return(get_next_message, 0);
        assert_true(handle_next_message() == -1);
}

int main() {
        const UnitTest tests[] = {
                unit_test(test_handle_next_message_success),
                unit_test(test_handle_next_message_fail)
        };
        return run_tests(tests);
}

执行结果：
test_handle_next_message_success: Starting test
test_handle_next_message_success: Test completed successfully.
test_handle_next_message_fail: Starting test
test_handle_next_message_fail: Test completed successfully.
All 2 tests passed