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

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

cmock网址:http://code.google.com/p/cmockery/

谷歌拥有优秀的测试框架。https://github.com/google/googletest/blob/master/googletest/docs/primer.md

是的，据我所知，它将与普通C一起工作，即不需要c++功能(可能需要c++编译器，不确定)。

cmock是最近推出的一个项目，由一个非常简单的C库组成，用于编写单元测试。

我不使用框架，我只是使用自动工具“检查”目标支持。实现一个“main”并使用assert。

我的测试目录Makefile.am(s)看起来像这样:

check_PROGRAMS = test_oe_amqp

test_oe_amqp_SOURCES = test_oe_amqp.c
test_oe_amqp_LDADD = -L$(top_builddir)/components/common -loecommon
test_oe_amqp_CFLAGS = -I$(top_srcdir)/components/common -static

TESTS = test_oe_amqp

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

测试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代码的单元测试，我强烈推荐这本书。