嵌入式开发中的测试驱动设计

在嵌入式软件开发中，很多代码质量问题并不是因为工程师不会写代码，而是因为代码开始得太早，设计开始得太晚。一个需求下来，很多人的开发流程往往是：看需求 → 写驱动 → 调硬件 → 编译 → 下载 → 示波器抓波形 → 修改代码 → 再下载。功能简单时，这种方式似乎没有问题。但随着需求增加，很容易出现几个典型现象：一个全局变量被越来越多模块使用；一个接口为了兼容新需求不断增加参数；硬件操作与业务逻辑混在一起；修改一个功能，影响多个模块；软件必须连接真实硬件才能验证；Bug 只能通过“烧进去跑一下”才能发现。最终，代码能够运行，但结构越来越复杂，后期维护成本越来越高。测试驱动开发（TDD）的价值，正是在编码之前引入一种更严格的思考方式：先定义系统应该表现出什么行为，再设计代码如何实现这个行为。对于嵌入式系统而言，TDD 不仅是一种测试方法，更是一种接口设计和架构设计方法。一、什么是 TDD：测试不是最后一步，而是设计的起点传统开发通常遵循这样的流程：需求 ↓ 设计 ↓ 编码 ↓ 测试 ↓ 修改而 TDD 则将测试提前：需求 ↓ 定义行为 ↓ 编写失败测试 ↓ 实现最小代码 ↓ 测试通过 ↓ 重构这个过程通常被称为：红 → 绿 → 重构1. 红：先让测试失败首先根据需求写一个测试。此时功能还没有实现，因此测试必然失败。这个失败非常重要，因为它证明：测试确实在验证你想实现的功能，而不是一个永远成功的“摆设”。2. 绿：实现最小功能接下来只写足够让测试通过的代码。注意，这里并不是一次性实现完整系统，而是：只解决当前测试所描述的问题。例如需求只是：LED 可以打开。那么第一步不需要考虑：多个 LED；PWM 调光；呼吸灯；闪烁模式；错误恢复。先让最基本行为成立。3. 重构：在测试保护下改善代码当测试通过后，再整理代码结构：消除重复代码；拆分模块；优化接口；降低耦合；提升可读性。因为已有测试作为保护网，所以可以更加放心地修改内部实现。这就是 TDD 的真正核心：测试不仅用于发现 Bug，更用于保护设计演进。二、从需求开始，而不是从函数开始假设现在有一个需求：系统需要控制 LED，可以打开、关闭，并支持指定频率闪烁。传统开发中，工程师可能马上创建：voidled_init(void);voidled_on(void);voidled_off(void);voidled_set_frequency(uint32_tfreq);voidled_blink_start(void);看起来没有问题。但实际上，这些接口已经隐含了大量设计假设：系统只有一个 LED；LED 是全局对象；初始化不需要参数；闪烁功能由 LED 模块自己管理；频率使用整数表示；LED 状态可以直接读取。这些设计是否合理？此时其实还不知道。因此，TDD 的第一步不是设计函数，而是描述行为。例如：voidtest_led_should_be_off_after_initialization(void){led_init();TEST_ASSERT_FALSE(led_is_on());}再例如：voidtest_led_can_be_turned_on(void){led_init();led_on();TEST_ASSERT_TRUE(led_is_on());}从测试中，我们开始反推出接口。于是发现系统至少需要：voidled_init(void);voidled_on(void);boolled_is_on(void);注意这个过程：接口不是凭经验直接设计出来的，而是从系统行为中逐渐生长出来的。三、第二个测试，往往比第一个测试更重要真正的接口问题，通常不会在第一个需求中暴露。还是 LED 的例子。第一版设计：void