4、测试框架选型：Unity/CMock 测试框架介绍、Google Test 在嵌入式中的应用、Python + Pytest 方案对比、框架选择决策树

做嵌入式自动化测试，第一步就卡在框架选型上。我见过不少团队，上来就拍脑袋选了个框架，结果写到一半发现跑不了，又得重来。说白了，选框架就像选工具——没有最好的，只有最合适的。

今天我就把市面上主流的三个方案掰开揉碎了讲。Unity/CMock、Google Test、Python + Pytest，它们各自适合什么场景？坑在哪里？最后我会给出一棵决策树，帮你快速锁定答案。

Unity + CMock：嵌入式测试的「原配」

Unity 是专门为嵌入式 C 语言写的测试框架。它有多轻量？整个框架就两个 .c 文件和一个 .h 头文件。我最早在 STM32 上跑 Unity，编译出来才 4KB 左右，这在资源受限的 MCU 上简直是福音。

它的核心用法很简单：

#include "unity.h"

void setUp(void) {}
void tearDown(void) {}

void test_led_toggle_should_work(void) {
    TEST_ASSERT_EQUAL(1, led_get_state());
    led_toggle();
    TEST_ASSERT_EQUAL(0, led_get_state());
}

int main(void) {
    UNITY_BEGIN();
    RUN_TEST(test_led_toggle_should_work);
    return UNITY_END();
}

CMock 是它的好搭档，专门做 mock 和 stub。我在项目中遇到过最头疼的事——驱动层还没写好，上层逻辑怎么测？CMock 能自动生成驱动函数的桩代码，让你先跑通业务逻辑。

我的习惯：Unity 适合跑在目标硬件上做「板级测试」。比如你要验证某个 GPIO 中断是否触发，直接在开发板上跑 Unity 用例，比在 PC 上模拟靠谱得多。

Google Test：PC 端的「重型武器」

Google Test（简称 GTest）是 C++ 的测试框架。你可能会问：「嵌入式不是用 C 吗？」嗯，这里有个关键点——GTest 通常跑在 PC 上，用来测试交叉编译前的逻辑代码。

举个例子。你写了一个 PID 控制算法，里面全是浮点运算和数学公式。这种代码在 MCU 上调试效率极低，每次烧录都要等 30 秒。我建议的做法是：先在 PC 上用 GTest 把算法逻辑测透，再移植到嵌入式平台。

#include <gtest/gtest.h>

TEST(PidControllerTest, ComputeOutput) {
    PidController pid(1.0, 0.1, 0.05);
    pid.set_setpoint(100.0);
    
    double output = pid.compute(90.0);
    EXPECT_NEAR(output, 10.5, 0.01);
}
注意：GTest 依赖 C++ 标准库和操作系统支持。别想着把它塞进只有 64KB Flash 的 MCU 里——我曾经试过，编译直接报内存不足。

Python + Pytest：系统级测试的「瑞士军刀」

Pytest 是 Python 生态里最流行的测试框架。它在嵌入式测试中的定位很明确——做系统级测试和集成测试。

你想想看，嵌入式产品最终要跟外部设备交互：串口通信、网络协议、传感器数据采集。这些场景用 C 语言写测试用例，代码量巨大。但用 Python，几行脚本就能搞定。

import pytest
import serial

def test_uart_echo():
    ser = serial.Serial('/dev/ttyUSB0', 115200)
    ser.write(b'hello')
    response = ser.read(5)
    assert response == b'hello'
    ser.close()

我个人习惯把 Pytest 用在「黑盒测试」场景。比如测试一个智能插座：发送开灯指令，检查电流是否变化。这种测试不关心内部代码，只验证外部行为。

三大框架对比：一张表说清楚

维度 Unity + CMock Google Test Python + Pytest
语言 C C++ Python
运行环境 MCU / PC PC（Linux/Windows） PC（需连接目标板）
代码体积 极小（~4KB） 较大（依赖 C++ 库） 依赖 Python 解释器
Mock 支持 CMock 自动生成 GMock 手动编写 unittest.mock
适用阶段 单元测试、板级测试 算法逻辑测试 系统测试、集成测试
学习成本 低 中 低（Python 基础）

框架选择决策树

说了这么多，到底怎么选？我总结了一棵决策树，你按顺序问自己三个问题就行：

  1. 测试要跑在 MCU 上吗？
    • 是 → 选 Unity + CMock
    • 否 → 看下一个问题
  2. 测试对象是纯算法逻辑吗？
    • 是 → 选 Google Test
    • 否 → 看下一个问题
  3. 需要跟外部硬件交互吗？
    • 是 → 选 Python + Pytest
    • 否 → 回到问题 1 重新评估

实战建议：我做过一个项目，用了「三合一」方案。底层驱动用 Unity 测，PID 算法用 GTest 在 PC 上跑，整机功能用 Pytest 做自动化。三个框架各司其职，互不干扰。这才是最理想的测试架构。

嗯，框架选型这块就聊到这儿。下一章我会手把手带你搭建 Unity + CMock 的测试环境，包括如何配置交叉编译链、如何把测试用例烧录到开发板上运行。到时候你就能体会到，在 MCU 上跑单元测试是什么感觉了。

← 上一章 📖 返回目录 下一章 →