046、使用单元测试框架测试FreeRTOS任务与模块：从一次深夜调试说起
凌晨两点，示波器上的波形还在跳动。我盯着屏幕里那个偶尔丢失的传感器数据包，已经排查了三小时硬件链路，最后才发现问题出在一个自以为“足够简单”的FreeRTOS任务——它在高优先级任务频繁抢占时，漏掉了一次队列读取。那一刻我意识到：在RTOS环境下，靠手动调试验证代码逻辑，就像用渔网筛沙子。
为什么FreeRTOS代码更需要单元测试？
嵌入式开发有个经典误区：认为硬件相关代码难测，所以干脆不测。但FreeRTOS引入的多任务、队列、信号量等机制，创造了新的复杂度维度。任务间的时序竞争、资源同步、优先级反转，这些问题在单次测试中可能潜伏数周才暴露。单元测试框架能帮你构建一个可控的“实验室”，模拟各种极端调度场景。
选型：嵌入式单元测试框架怎么选？
别一上来就追求大而全。我试过Unity+CMock组合，也用过CppUTest，最后在资源紧张的STM32F103上回归了最简单的Unity。为什么？因为很多MCU的Flash还没你电脑的缓存大。记住原则：测试框架本身不应该成为系统的负担。
// 不好的例子：在ISR里调用完整的Unity断言voidUSART1_IRQHan
