嵌入式单测别只盯终端：轻量框架和 Unity/CUnit差在哪

大家好，我是杂烩君。

嵌入式这边写 C，单测到底要不要上？

Unity、CUnit 用过一点，终端一刷就完事；领导偶尔问覆盖率、有没有泄漏，又得另开一堆工具，报告还不好给人看。

很多同学并不是「不会写断言」，而是卡在后半截：结果怎么沉淀、怎么给别人看、怎么和覆盖率/性能/泄漏对上。

本次介绍个偏轻量的开源项目 Mini CUnitTest，可以输出网页报告，可以当一个可参考方向。

经典断言库（Unity、CUnit 一类）：断言清晰、成熟稳定，资料也多。报告多半落在终端或 CI log。覆盖率、泄漏往往要自己拼 gcov、valgrind 等。适合流水线已经齐了、只差可靠断言的人。

工程化全家桶（Ceedling、gtest 一类）：工程化强、好接 CI，mock、构建、插件生态更完整，但门槛和配置更重，本地观感仍偏「工程工具」。适合大工程、完整构建体系、愿意为规范付学习成本的团队。

轻量网页报告型（Mini CUnitTest 这类）：核心就关联 TEST.c，再用 UnitTest.py 串编译、执行、解析，吐出 HTML。适合想快速给人看报告，主机或带 Python/gcc 的环境。它省的是拼装时间，不是替你做架构决策。

Mini CUnitTest 简介

Mini CUnitTest是一个面向 C 语言的轻量单元测试框架，把写用例 → 编译跑 → 出网页报捆成一条最小闭环。

https://gitee.com/dcp_483/minicunittest

它能做什么，对应到项目里大致是这些：

用例套件：TEST_SUITE / TEST_CASE 一类宏，suite 里能看到用例数、失败数、耗时，失败时还能落到具体 case。

覆盖率：走 gcov，报告里有语句、分支、条件、函数等覆盖信息，还能顺着代码看。

函数性能：走 gprof（偏 Linux），看执行时间、调用次数。

内存泄漏：Linux 上可用 mcheck 一类能力做侦查展示；Mac 上这块和性能能力目前并不完整。

对嵌入式读者更关键的是：它不只是主机脚本，还留了 -a / -e / -m 几条路径——本机快试、Makefile 接入、板上跑二进制再回主机汇总，都有入口。

这对「主机写测、目标跑测、主机看报告」的常见分工，比较友好。

流水线长这样：

![UnitTest.py 三种模式选型](嵌入式单测别只盯终端：轻量框架和 Unity、CUnit 差在哪.assets/20260821001619670.png)

和经典框架比，我们可以这样理解差异：Unity/CUnit 更像「断言积木」；Mini CUnitTest 更像「断言 + 一键出报告的小流水线」。前者生态更老牌，后者观感更直观。

配置主要在 UnitTest.py 顶部几行：把 UnitPath、FilePath 改成你的单元测试目录和待测源码目录（以 / 结尾），再在 TestFile、GccFile 里填上要测、要关联编译的文件。

写 case 的样子很直白，项目自带的示例大概是这种风格：

TEST_SUITE_START(测试case接口正常使用)
    TEST_CASE(test_success_case, case成功测试, 测试当case成功的情况);
TEST_SUITE_END

下面三张是项目 README 里的演示，感受下报告长什么样：

测试报告页

测试报告页面演示

覆盖率页

覆盖率页面演示

函数性能页

用之前，这几点需要注意：

脚本偏老：UnitTest.py 一带有较老的 Python 写法（例如 print 语句风格），新环境可能要先适配。

平台能力不均：内存泄漏、gprof 性能更偏 Linux；Mac 上这两块目前支持不完整。做演示尽量选 Linux 主机或 Linux 开发板环境。

依赖本机工具链：报告质量绑在 gcov、gprof、gcc 参数上；嵌入式交叉编译时，flags 和路径要想清楚，板端能不能跑 Python、能不能回传产物，也要提前确认。

不是替代一切：已有完整 CI、只缺断言库，继续 Unity/CUnit 往往更省事；不必为了 HTML 强行迁移。

AI 能帮你搜命令、解释宏、草拟 case，但板子差异、编译报错、驱动适配、日志定位，还是得自己碰。

欢迎大家评论区聊聊，分享你在用的单元测试方案。