今年夏天,我开发了一个用纯c语言编写的嵌入式系统。这是我所在公司接管的一个现有项目。我已经非常习惯使用JUnit在Java中编写单元测试,但不知道为现有代码(需要重构)和添加到系统中的新代码编写单元测试的最佳方法是什么。

有什么项目可以让单元测试纯C代码像使用JUnit测试Java代码一样简单吗?任何特别适用于嵌入式开发(交叉编译到arm-linux平台)的见解都将非常感谢。


当前回答

这是CUnit

嵌入式单元是嵌入式C系统的单元测试框架。它的设计抄袭了JUnit和CUnit等,然后为嵌入式C系统做了一些调整。嵌入式单元不需要标准C库。所有对象都分配到const区域。

Tessy自动化了嵌入式软件的单元测试。

其他回答

我编写Libcut只是出于对现有C单元测试库的不满。它具有原语的自动类型字符串(不需要test_eq_int, test_eq_long, test_eq_short,等等…)对于原语和字符串只有两个不同的集合),并且由一个头文件组成。这里有一个简短的例子:

#include <libcut.h>

LIBCUT_TEST(test_abc) {
    LIBCUT_TEST_EQ(1, 1);
    LIBCUT_TEST_NE(1, 0);
    LIBCUT_TEST_STREQ("abc", "abc");
    LIBCUT_TEST_STRNE("abc", "def");
}

LIBCUT_MAIN(test_abc);

不过,它只对C11有效。

使用的一种技术是使用c++ xUnit框架(和c++编译器)开发单元测试代码,同时将目标系统的源代码维护为C模块。

确保在交叉编译器下定期编译C源代码,如果可能的话自动使用单元测试。

除了我明显的偏见

http://code.google.com/p/seatest/

是一个很好的简单的方法来单元测试C代码。模仿xUnit

C语言有一个优雅的单元测试框架,它支持模拟对象,叫做cmocka。它只需要标准的C库,适用于各种计算平台(包括嵌入式)和不同的编译器。

它还支持不同的消息输出格式,如Subunit、Test Anything Protocol和jUnit XML报告。

cmocka也可以在嵌入式平台上工作,也支持Windows。

一个简单的测试是这样的:

#include <stdarg.h>
#include <stddef.h>
#include <setjmp.h>
#include <cmocka.h>

/* A test case that does nothing and succeeds. */
static void null_test_success(void **state) {
    (void) state; /* unused */
}

int main(void) {
    const struct CMUnitTest tests[] = {
        cmocka_unit_test(null_test_success),
    };
    return cmocka_run_group_tests(tests, NULL, NULL);
}

API有完整的文档,源代码中有几个示例。

要开始使用cmocka,您应该阅读LWN.net上的文章:在C中使用模拟对象进行单元测试

cmocka 1.0已于2015年2月发布。

我个人喜欢谷歌测试框架。

测试C代码的真正困难在于打破对外部模块的依赖,这样就可以将代码分离成单元。当您试图围绕遗留代码进行测试时,这可能尤其成问题。在这种情况下,我经常发现自己在测试中使用链接器来使用存根函数。

这就是人们在谈论“接缝”时所指的东西。在C语言中,你唯一的选择就是使用预处理器或链接器来模拟依赖项。

在我的一个C项目中,典型的测试套件可能是这样的:

#include "myimplementationfile.c"
#include <gtest/gtest.h>

// Mock out external dependency on mylogger.o
void Logger_log(...){}

TEST(FactorialTest, Zero) {
    EXPECT_EQ(1, Factorial(0));
}

注意,您实际上包含的是C文件,而不是头文件。这提供了访问所有静态数据成员的优势。这里我模拟了我的记录器(可能在logger中)。O并给出一个空的实现。这意味着测试文件独立于其余代码库进行编译和链接,并独立执行。

至于交叉编译代码,您需要在目标上使用良好的工具。我使用googletest交叉编译到PowerPC体系结构上的Linux来实现这一点。这是有意义的,因为您有一个完整的shell和os来收集结果。对于不太丰富的环境(我将其归类为没有完整操作系统的任何环境),您应该只在主机上构建和运行。无论如何您都应该这样做,这样您就可以作为构建的一部分自动运行测试。

我发现测试c++代码通常要容易得多,因为OO代码通常比过程性代码耦合得少(当然这在很大程度上取决于编码风格)。此外,在c++中,你可以使用依赖注入和方法重写等技巧来将接缝插入封装的代码中。

Michael Feathers有一本关于测试遗留代码的优秀书籍。在其中一章中,他介绍了处理非oo代码的技巧,我强烈推荐这些技巧。

编辑:我写了一篇关于单元测试过程代码的博客文章,源代码可以在GitHub上找到。

编辑:Pragmatic Programmers出版了一本新书,专门介绍了C代码的单元测试,我强烈推荐这本书。