嵌入式单元测试的特殊性：硬件依赖、资源受限、实时性要求、交叉编译环境

说实话，很多从纯软件转过来的同事，第一次接触嵌入式单元测试时都会懵。我当年也一样——拿着JUnit那套思路往嵌入式项目里套，结果碰了一鼻子灰。为什么？因为嵌入式环境跟桌面开发完全是两码事。

这一章，我就把嵌入式单元测试最核心的四个特殊性掰开揉碎讲清楚。你理解了这些，后面搭建框架时才能有的放矢。

硬件依赖：你的代码跑在真实芯片上

桌面程序写完了，双击就能跑。嵌入式呢？你得先烧录、接线、上电。更麻烦的是，很多代码直接操作寄存器、中断控制器、外设接口。这些逻辑在PC上根本没法直接测。

举个例子，一个GPIO翻转函数：

void gpio_toggle(GPIO_TypeDef *gpio, uint16_t pin) {
    if (gpio->ODR & pin) {
        gpio->BRR = pin;  // 复位
    } else {
        gpio->BSRR = pin; // 置位
    }
}

这段代码直接操作内存映射寄存器。你在PC上跑单元测试，根本访问不到0x40020000这个地址。怎么办？

我在项目中遇到过最头疼的情况：一个电机驱动库，底层直接操作PWM寄存器。为了做单元测试，我不得不抽出一个pwm_if.h接口层，然后写了一个模拟PWM模块，用软件定时器模拟占空比变化。虽然工作量大了点，但后续每次改逻辑都能快速验证，值了。

硬件依赖类型	测试策略	典型做法
寄存器操作	模拟内存映射	定义结构体指针指向模拟RAM
外设中断	事件模拟	手动触发中断回调函数
DMA传输	数据注入	预置缓冲区内容，模拟传输完成
ADC采样	固定值/序列值	模拟层返回预设采样数据

资源受限：内存不是无限的

桌面开发习惯了new对象不心疼，嵌入式可不行。一个STM32F103只有20KB RAM，你一个测试用例就吃掉10KB，剩下的代码还跑不跑了？

我建议你在设计测试框架时，从一开始就把资源约束刻在脑子里。具体来说：

• 静态分配优先：能不用malloc就不用。测试用例的缓冲区、桩函数的数据区，全部静态声明。
• 栈空间精打细算：每个测试用例的局部变量总量控制在几百字节以内。我见过一个同事的测试函数里声明了4KB的局部数组，结果一跑就栈溢出。
• 代码体积要控制：测试框架本身也会占用Flash。选择轻量级的框架，比如Unity、CMock，它们编译出来只有几KB。

为什么会这样？因为嵌入式单元测试往往要在目标板上执行，或者至少要在模拟环境中考虑资源限制。你想想看，一个跑在RTOS上的任务，原本栈空间就只给了1KB，你的测试代码如果用了800字节，那任务逻辑还怎么跑？

实时性要求：时间不是无限的

桌面程序慢个几百毫秒，用户可能只是皱皱眉。嵌入式系统呢？一个刹车控制信号延迟5毫秒，可能就是事故。

单元测试不能破坏原有的实时行为。我遇到过这样的坑：在测试一个CAN通信模块时，我在每个测试用例前后加了大量printf调试输出，结果CAN报文的发送时序全乱了——因为printf本身就要花好几毫秒。

几个实用原则：

• 测试用例执行时间要稳定：同一个用例每次跑的时间差异不要超过10%。如果发现波动，先排查是不是有轮询等待或不确定循环。
• 避免在中断上下文中做复杂测试：中断服务程序里只做标志位设置，真正的测试逻辑放在任务级。
• 使用时间戳桩函数：模拟HAL_GetTick()这类时间接口，让测试用例可以控制时间流逝。

// 模拟时间接口示例
static uint32_t mock_tick = 0;

uint32_t HAL_GetTick(void) {
    return mock_tick;
}

void mock_tick_advance(uint32_t ms) {
    mock_tick += ms;
}

// 测试超时逻辑
void test_timeout_handling(void) {
    mock_tick = 1000;
    start_operation();
    mock_tick_advance(5000);  // 模拟5秒过去
    TEST_ASSERT_TRUE(is_timeout());
}

交叉编译环境：编译和运行不在同一台机器

这是嵌入式开发特有的痛点。你在PC上写代码，用交叉编译器生成ARM或RISC-V的机器码，然后烧到目标板上跑。单元测试怎么办？

有三种策略，我按推荐程度排个序：

1. 主机测试（推荐）：用本地编译器（gcc/clang）编译测试用例，直接在PC上跑。速度快，调试方便。缺点是需要模拟硬件层。
2. 目标板测试：交叉编译后烧录到目标板执行。结果最真实，但速度慢，调试困难。
3. 模拟器测试：用QEMU等模拟器运行交叉编译的二进制。折中方案，适合集成测试。

我个人习惯是：逻辑层用主机测试，硬件层用目标板测试。比如一个PID控制算法，纯数学运算，完全可以在PC上测。但如果是ADC中断触发的PID更新，那就得在目标板上验证时序。

// 平台隔离示例
#ifdef UNIT_TEST
    // 测试用模拟实现
    #include "mock_adc.h"
#else
    // 真实硬件实现
    #include "stm32f1xx_hal_adc.h"
#endif

float read_temperature(void) {
    #ifdef UNIT_TEST
        return mock_adc_read(ADC_CH_TEMP);
    #else
        HAL_ADC_Start(&hadc1);
        HAL_ADC_PollForConversion(&hadc1, 100);
        return HAL_ADC_GetValue(&hadc1) * 0.076;  // 真实转换
    #endif
}

四个特殊性的关系

这四个点不是孤立的，它们互相影响。我画了一张图帮你理清关系：

你看，硬件依赖决定了你要做模拟层；资源受限限制了你的测试框架选型和用例设计；实时性要求你控制测试代码的时间开销；交叉编译环境则决定了你的测试在哪里跑、怎么跑。这四个点拧在一起，就是嵌入式单元测试跟普通软件测试最大的不同。