Answers:
有很多变量将决定您所用的最佳单元测试框架。可能会影响您选择的一些项目是：
大多数xUnit类型框架将提供一些基本级别的功能，这些功能可能会很有用。我过去使用Cunit取得了一些成功。（Ubuntu / Debian上的libcunit1-dev软件包）。大多数框架将需要libc可用，某些框架需要附加的OS支持。
我发现以微控制器为目标的单元测试非常麻烦，因为您需要能够提供一个适合下载测试，运行测试然后返回结果的环境。仅使平台就位，这将使您能够完成此任务。
我采用的另一种对我有用的方法是在主机上进行单元测试，在驱动程序和应用程序代码之间实现抽象层。由于您将gcc用作目标，因此代码也应在主机上编译。
通常，有了主机操作系统及其所有工具的全面支持，在编译主机上进行测试通常要容易得多。例如，在主机上进行测试时，我有一个无线驱动程序的模拟版本，其接口与在目标上运行的真实驱动程序相同。主机版本使用UDP数据包模拟无线数据包传输，而模拟驱动程序支持丢弃数据包的功能，因此我可以测试协议。
在我正在开发的产品中，正在使用线程操作系统，因此用于在主机操作系统上进行测试的抽象层使用了pthread。
虽然不是很完美，但是编写和运行测试越容易，实现更多测试用例的可能性就越大。使代码在不同平台上运行的另一个好处是测试代码是否可移植。如果目标和主机体系结构不同，您将很快发现字节序错误。
我现在谈的有点不对，但是觉得这些想法可能对您选择测试框架和测试方法有所帮助。
查看embUnit http://embunit.sourceforge.net/embunit/index.html。它是具有低占用空间的嵌入式C单元测试框架。
我们在几个嵌入式微控制器项目中成功使用了它。不要期望桌面单元测试框架提供的选项和功能。但这绝对足够强大。
它为您定义了断言的分配，因此您不必浪费时间编写与minUnit一样的自定义断言。
前段时间，我写了一篇有关该主题的详尽教程：使用Ceedling对单元测试（嵌入式）C应用程序；我在很多项目中都使用了这些技术，到目前为止我还很高兴。
我只是自己调查一下。我在这里找到了一个由三部分组成的文章，概述了单元测试框架：
我也同意奥斯丁所说的一切。