C语言中的一个单元测试框架是Check;C语言单元测试框架的列表可以在这里找到，并在下面复制。根据运行时具有多少标准库函数，您可以使用其中的一个，也可以不使用。

AceUnit AceUnit (Advanced C and Embedded Unit) bills itself as a comfortable C code unit test framework. It tries to mimick JUnit 4.x and includes reflection-like capabilities. AceUnit can be used in resource constraint environments, e.g. embedded software development, and importantly it runs fine in environments where you cannot include a single standard header file and cannot invoke a single standard C function from the ANSI / ISO C libraries. It also has a Windows port. It does not use forks to trap signals, although the authors have expressed interest in adding such a feature. See the AceUnit homepage. GNU Autounit Much along the same lines as Check, including forking to run unit tests in a separate address space (in fact, the original author of Check borrowed the idea from GNU Autounit). GNU Autounit uses GLib extensively, which means that linking and such need special options, but this may not be a big problem to you, especially if you are already using GTK or GLib. See the GNU Autounit homepage. cUnit Also uses GLib, but does not fork to protect the address space of unit tests. CUnit Standard C, with plans for a Win32 GUI implementation. Does not currently fork or otherwise protect the address space of unit tests. In early development. See the CUnit homepage. CuTest A simple framework with just one .c and one .h file that you drop into your source tree. See the CuTest homepage. CppUnit The premier unit testing framework for C++; you can also use it to test C code. It is stable, actively developed, and has a GUI interface. The primary reasons not to use CppUnit for C are first that it is quite big, and second you have to write your tests in C++, which means you need a C++ compiler. If these don’t sound like concerns, it is definitely worth considering, along with other C++ unit testing frameworks. See the CppUnit homepage. embUnit embUnit (Embedded Unit) is another unit test framework for embedded systems. This one appears to be superseded by AceUnit. Embedded Unit homepage. MinUnit A minimal set of macros and that’s it! The point is to show how easy it is to unit test your code. See the MinUnit homepage. CUnit for Mr. Ando A CUnit implementation that is fairly new, and apparently still in early development. See the CUnit for Mr. Ando homepage. This list was last updated in March 2008.

更多的框架:

CMocka

CMocka是一个支持模拟对象的C语言测试框架。它易于使用和设置。

请参阅CMocka主页。

标准

Criterion是一个跨平台的C单元测试框架，支持自动测试注册、参数化测试和理论，可以输出多种格式，包括TAP和JUnit XML。每个测试都在自己的进程中运行，因此如果需要，可以报告或测试信号和崩溃。

更多信息请参阅Criterion主页。

HWUT

HWUT是一个通用的单元测试工具，支持c语言。它可以帮助创建makefile，生成大量的测试用例，在最小的“迭代表”中编码，运行状态机，生成c语言存根等等。一般的方法是非常独特的:裁决是基于“好标准输出/坏标准输出”。不过，比较函数是灵活的。因此，任何类型的脚本都可以用于检查。它可以应用于任何可以产生标准输出的语言。

请参阅武汉理工大学主页。

CGreen

一个现代的、可移植的、跨语言的C和c++单元测试和模拟框架。它提供了可选的BDD表示法、模拟库和在单个进程中运行它的能力(使调试更容易)。一个自动发现测试函数的测试运行器是可用的。但是您可以通过编程方式创建自己的。

所有这些特性(以及更多)在CGreen手册中都有解释。

维基百科在单元测试框架列表下给出了C单元测试框架的详细列表:C

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

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

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

如果你熟悉JUnit，那么我推荐CppUnit。 http://cppunit.sourceforge.net/cppunit-wiki

这是假设你有c++编译器来做单元测试。如果没有，那么我必须同意亚当·罗森菲尔德的观点，支票就是你想要的。

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

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

这是CUnit

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

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

Minunit是一个非常简单的单元测试框架。 我用它来单元测试c微控制器代码avr。

首先，看看这里:http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C

我的公司有一个客户使用的C库。我们使用CxxTest(一个c++单元测试库)来测试代码。CppUnit也可以工作。如果你被C卡住了，我推荐RCUNIT(但CUnit也很好)。

我将CxxTest用于嵌入式c/c++环境(主要是c++)。

我更喜欢CxxTest，因为它有一个perl/python脚本来构建测试运行器。在进行了一些设置之后(因为不需要编写测试运行程序，所以还会更小)，它非常容易使用(包括示例和有用的文档)。大部分工作是设置代码访问的“硬件”，这样我就可以有效地进行单元/模块测试。在此之后，很容易添加新的单元测试用例。

如前所述，它是一个C/ c++单元测试框架。所以你需要一个c++编译器。

CxxTest用户指南 CxxTest维基

您可能还想看看libtap，这是一个输出任何测试协议(TAP)的C测试框架，因此可以很好地与用于该技术的各种工具集成。它主要用于动态语言领域，但它易于使用，并且变得非常流行。

一个例子:

#include <tap.h>

int main () {
    plan(5);

    ok(3 == 3);
    is("fnord", "eek", "two different strings not that way?");
    ok(3 <= 8732, "%d <= %d", 3, 8732);
    like("fnord", "f(yes|no)r*[a-f]$");
    cmp_ok(3, ">=", 10);

    done_testing();
}

我不使用框架，我只是使用自动工具“检查”目标支持。实现一个“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

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

我目前正在使用CuTest单元测试框架:

http://cutest.sourceforge.net/

它是嵌入式系统的理想选择，因为它非常轻量级和简单。让它在目标平台和桌面上运行都没有问题。除了编写单元测试，所需要的是:

头文件包含在任何地方 你称之为最可爱的程序 一个额外的“C”文件 编译/链接到映像 一些简单的代码添加到主要到 设置并调用单元测试- I 只需要把它放在一个特殊的main()中 函数，如果 过程中定义UNITTEST 构建。

系统需要支持堆和一些stdio功能(不是所有的嵌入式系统都有)。但是代码非常简单，如果您的平台没有这些需求，您可能可以使用这些需求的替代方案。

通过明智地使用extern“C”{}块，它还可以很好地支持测试c++。

如果您的目标是Win32平台或NT内核模式，您应该看看cfix。

在测试目标之前，我使用RCUNIT在PC上对嵌入式代码进行了一些单元测试。好的硬件接口抽象很重要，否则字节顺序和内存映射寄存器会害死你。

如果你还在寻找测试框架，CUnitWin32是Win32/NT平台的一个。

这解决了我在其他测试框架中遇到的一个基本问题。也就是说，全局/静态变量处于确定性状态，因为每个测试都是作为单独的进程执行的。

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

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

Michael Feather的书《有效地使用遗留代码》介绍了很多专门用于C开发期间单元测试的技术。

有一些与依赖注入相关的技术是特定于C语言的，我在其他任何地方都没有见过。

LibU (http://koanlogic.com/libu)有一个单元测试模块，允许显式测试套件/用例依赖、测试隔离、并行执行和可定制的报告格式化器(默认格式是xml和txt)。

这个库是BSD许可的，包含许多其他有用的模块——网络、调试、常用的数据结构、配置等等——如果你的项目需要它们的话……

除了我明显的偏见

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

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

在开始寻找模拟函数的方法之前，我还没有深入测试遗留的C应用程序。我非常需要mock来将我想测试的C文件与其他C文件隔离开来。我试过cmock，我想我会采用它。

Cmock扫描头文件，并根据它找到的原型生成模拟函数。mock将允许您在完全隔离的情况下测试C文件。您所要做的就是将您的测试文件链接到模拟对象，而不是真正的对象文件。

cmock的另一个优点是，它将验证传递给模拟函数的参数，并允许您指定模拟函数应该提供的返回值。这对于在函数中测试不同的执行流非常有用。

测试由典型的testA()、testB()函数组成，您可以在其中构建期望、调用函数来测试和检查断言。

最后一步是为unity的测试生成一个运行器。Cmock绑定到统一测试框架。Unity和其他单元测试框架一样容易学习。

很值得一试，而且很容易掌握:

http://sourceforge.net/apps/trac/cmock/wiki

更新1

我正在研究的另一个框架是cmock。

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

它是一个支持单元测试和模拟的纯C框架。它不依赖于ruby(与Cmock相反)，也很少依赖于外部库。

它需要更多的手工工作来设置模拟，因为它不生成代码。这并不代表现有项目的大量工作，因为原型不会有太大的变化:一旦有了mock，就暂时不需要更改它们(这是我的例子)。额外的类型提供了对模拟的完全控制。如果有什么你不喜欢的，你只需改变你的mock。

不需要特别的测试人员。您只需要创建一个测试数组，并将其传递给run_tests函数。这里也有更多的手工工作，但我绝对喜欢自包含自治框架的想法。

此外，它还包含了一些我不知道的漂亮的C技巧。

总的来说，cmock需要对mock有更多的理解才能开始。例子可以帮助你克服这个问题。看起来它可以用更简单的机制来完成这项工作。

尝试lcut !- http://code.google.com/p/lcut

API完整性检查器- C/ c++库的测试框架:

An automatic generator of basic unit tests for a shared C/C++ library. It is able to generate reasonable (in most, but unfortunately not all, cases) input data for parameters and compose simple ("sanity" or "shallow"-quality) test cases for every function in the API through the analysis of declarations in header files. The quality of generated tests allows to check absence of critical errors in simple use cases. The tool is able to build and execute generated tests and detect crashes (segfaults), aborts, all kinds of emitted signals, non-zero program return code and program hanging.

例子:

fontconfig 2.8.0测试套件 FreeType 2.4.8的测试套件

在阅读Minunit之后，我认为更好的方法是在assert宏中进行测试，我使用了很多防御程序技术。所以我使用Minunit混合标准断言的相同思想。您可以在k0ga的博客中看到我的框架(一个好名字可以是NoMinunit)

CppUTest—强烈推荐用于单元测试C代码的框架。

书中提到的嵌入式C线程TDD中的示例是使用CppUTest编写的。

作为一个C语言新手，我发现名为“C测试驱动开发”的幻灯片非常有用。基本上，它使用标准assert()和&&来传递消息，没有任何外部依赖。如果有人习惯了全栈测试框架，这可能就不适用了:)

我说几乎和ratkok一样，但如果你有一个嵌入的扭曲单元测试，那么……

Unity——强烈推荐用于单元测试C代码的框架。

#include <unity.h>

void test_true_should_be_true(void)
{
    TEST_ASSERT_TRUE(true);
}

int main(void)
{
    UNITY_BEGIN();
    RUN_TEST(test_true_should_be_true);
    return UNITY_END();
}

书中提到的嵌入式C线程TDD中的例子是使用Unity(和CppUTest)编写的。

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月发布。

我很惊讶没有人提到卡特(http://cutter.sourceforge.net/) 你可以测试C和c++，它与autotools无缝集成，并且有一个非常好的教程。

我们编写CHEAT(托管在GitHub上)是为了便于使用和移植。

它没有依赖关系，不需要安装或配置。 只需要一个头文件和一个测试用例。

#include <cheat.h>

CHEAT_TEST(mathematics_still_work,
    cheat_assert(2 + 2 == 4);
    cheat_assert_not(2 + 2 == 5);
)

测试编译成一个可执行文件，负责运行测试并报告测试结果。

$ gcc -I . tests.c
$ ./a.out
..
---
2 successful of 2 run
SUCCESS

它也有漂亮的颜色。

我编写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有效。