我们如何像C中的测试那样执行单元测试？我们在哪个代码框架上执行其他测试作为单元测试？

解决方案

Check是C的良好测试框架。

Mac上的XCode内置了一些称为CPTest的东西。我做了一个便携式版本，我在这里发布了

http://www.loufranco.com/blog/files/AppleCppUnitPort.html

我当时的目标是Windows上的gcc，但我想它可以在其他地方使用，如果我们想了解如何实现这种功能，这是一个非常简单的框架。

我们可以在www.xprogramming.com上找到有关许多C单元测试框架的信息，尤其是在软件链接上。

我们可能想看一下cfix-它是专门用于Win32平台和NT内核模式的单元测试框架。同时支持C和C ++。

如果我们使用Windows作为开发环境，则CUnitWin32可能会满足目的

我个人喜欢Google Test框架。

测试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中，并提供了一个空的实现。这意味着测试文件独立于其余代码库进行编译和链接，并独立执行。

至于交叉编译代码，要使其正常工作，我们需要在目标设备上提供良好的工具。我通过在PowerPC架构上编译为Linux的googletest cross来完成此任务。这是有道理的，因为在那里有一个完整的shell和os来收集结果。对于不太丰富的环境(我将其归类为没有完整操作系统的所有内容)，我们应该仅在主机上构建并运行。无论如何，我们都应该这样做，以便我们可以在构建过程中自动运行测试。

我发现测试C ++代码通常要容易得多，这是因为OO代码通常比过程耦合少(当然，这在很大程度上取决于编码样式)。同样，在C ++中，我们可以使用诸如依赖注入和方法重写之类的技巧来将接缝插入以其他方式封装的代码中。

迈克尔·费瑟斯(Michael Feathers)有一本关于测试遗留代码的极好的书。在一个章节中，他介绍了我强烈推荐的处理非OO代码的技术。

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