嵌入式测试

Unity:《一个可应用于嵌入式的轻量级单元测试框架》。核心只有 unity.c + unity.h + unity_internals.h共3个文件。对于中大型嵌入式项目，建议用 fixture 扩展来做“模块级测试集”，更易维护，也更接近常见的 xUnit 测试习惯。

CMock与Unity：《一个可自动生成嵌入式Mock模块的工具》

　　单元测试真正难的不是框架，而是有没有做好相关隔离。CMock + Unity 提供的是一条工程化、可落地的单元测路径：解析头文件自动生成 Mock，我们可以把时间花在设计用例和理解逻辑上。

假如B模块依赖A模块，在B已完成而A没有完成时想用Unity先对B模块进行测试此时可以：先准备模块A的头文件modeA.h和CMock 配置 文件cmock_config.yml，然后利用命令ruby ../lib/cmock.rb -ocmock config.yml src/temperature sensor.h一键生成mock_modeA.h和　mock_modeA.c；最后B模块包含mock_modeA.h就能进行测试了。等模块A开发完成在对A进行针对性测试。打桩的核心是对实际要调用的模块A文件重定向成了mock_modeA.h(即用mock_modeA.h代替modeA.h）

• Mock（模拟）：创建一个 “假的” 依赖模块（如硬件驱动、第三方接口、复杂算法模块），其对外接口与真实模块完全一致，但内部逻辑是简化的（仅满足被测试模块的需求）。
• 打桩（Stub）：通过技术手段，将被测试代码中对真实依赖模块的调用，“拦截并替换” 为对 Mock 模块的调用 —— 相当于在调用链路中 “打一个桩子”，让请求绕到 Mock 模块