摆脱开发板限制：基于 Google Test + Mock 的嵌入式 TDD 实践

2. 编写业务逻辑 (只依赖接口)

// DataLogger.h
#include "IFlash.h"
#include "ISensor.h"

class DataLogger {
    IFlash& m_flash; // 引用接口，而非具体类
    ISensor& m_sensor;
public:
    // 依赖注入：在构造时传入具体的实现
    DataLogger(IFlash& flash, ISensor& sensor) : m_flash(flash), m_sensor(sensor) {}
    
    void Process() {
        float val = m_sensor.ReadVoltage();
        if (val > 50.0f) {
            // 写入地址 0，模拟 4 字节数据
            bool success = m_flash.Write(0, (uint8_t*)&val, 4);
            if (!success) {
                // 如果写入失败，尝试擦除
                m_flash.Erase(0);
            }
        }
    }
};

三、核心武器：Google Mock

现在我们想测试 DataLogger。在 STM32 上，我们会传入真实的 Stm32Flash 类；但在 PC 上，我们传入一个**'骗子' (Mock Object)**。

Google Mock 可以自动生成这个'骗子'，并允许我们控制它的行为。

1. 定义 Mock 类

#include <gmock/gmock.h>
#include "IFlash.h"
#include "ISensor.h"

class MockFlash : public IFlash {
public:
    // MOCK_METHOD(返回值，函数名，(参数...), (修饰符));
    MOCK_METHOD(bool, Write, (uint32_t, const uint8_t*, size_t), (override));
    MOCK_METHOD(bool, Erase, (uint32_t), (override));
};

class MockSensor : public ISensor {
public:
    MOCK_METHOD(float, ReadVoltage, (), (override));
};

四、实战：编写单元测试用例

我们不需要编译到 ARM，直接用 gcc/clang 编译成 PC 的 exe 运行。

测试场景 1：正常记录数据

#include <gtest/gtest.h>

TEST(LoggerTest, ShouldWriteWhenVoltageHigh) {
    // 1. 准备 Mock 对象
    MockFlash flash;
    MockSensor sensor;
    DataLogger logger(flash, sensor);
    
    // 2. 设置期望 (Expectations)
    // 当调用 sensor.ReadVoltage 时，请返回 60.0 (超过阈值)
    EXPECT_CALL(sensor, ReadVoltage()).WillOnce(testing::Return(60.0f));
    // 期待 flash.Write 被调用一次，且返回 true
    EXPECT_CALL(flash, Write(0, testing::_, 4)).WillOnce(testing::Return(true));
    
    // 3. 执行业务
    logger.Process();
}

测试场景 2：Flash 写满自动擦除 (很难在板子上测！)

TEST(LoggerTest, ShouldEraseWhenWriteFails) {
    MockFlash flash;
    MockSensor sensor;
    DataLogger logger(flash, sensor);
    
    // 1. 模拟电压超限
    EXPECT_CALL(sensor, ReadVoltage()).WillOnce(testing::Return(60.0f));
    
    // 2. 【关键】模拟 Flash 写入失败 (返回 false)
    EXPECT_CALL(flash, Write(testing::_, testing::_, testing::_))
        .WillOnce(testing::Return(false));
    
    // 3. 验证：由于写入失败，logger 应该调用 Erase
    EXPECT_CALL(flash, Erase(0)).Times(1);
    
    // 4. 执行
    logger.Process();
}

五、进阶技巧：如何 Mock 只有 C 接口的库？

很多时候我们无法修改底层代码，比如 HAL 库只有 C 函数 HAL_GPIO_WritePin。这时候可以使用 Linker Seam (链接器接缝) 或 虚函数适配器。

推荐做法：适配器模式 (Adapter Pattern)

不要直接在业务代码里调 HAL_xxx。

1. 定义 IGpio C++ 接口。
2. 写一个 Stm32Gpio 类实现该接口，内部调用 HAL_GPIO_WritePin。
3. 业务代码只用 IGpio。
4. 测试代码 Mock IGpio。

硬核做法：弱符号覆盖 (Weak Symbol Override)

如果 HAL 库里的函数是 __weak 的（STM32 HAL 大部分中断回调都是 weak），你可以在测试工程里重新定义这个 C 函数，在里面植入测试逻辑。

六、为什么这是'降维打击'？

1. 速度：PC 运行测试只需要 0.1 秒。板子烧录运行需要 2 分钟。
2. 覆盖率：你能测试'Flash 损坏'、'I2C 总线超时'、'网络断连'等硬件上极难复现的异常情况。
3. 重构底气：当你优化算法时，跑一遍测试，全绿。你敢保证代码没改坏。如果没有测试，你改一行代码都心惊胆战。
4. 架构优化：为了能测试，你被迫把代码写成'低耦合'的接口形式。代码结构变好了，是测试带来的副作用。

七、总结

嵌入式开发不应该等同于'硬件调试'。

通过引入 Google Test 和 Mock 技术，我们将嵌入式开发拆解为两部分：

1. 在 Host 端：通过 TDD 验证 95% 的业务逻辑、状态机跳转、协议解析。
2. 在 Target 端：只验证剩下的 5% —— 驱动是不是真的能点亮 LED。

这就是现代嵌入式软件工程：用软件的思维写嵌入式，而不是用电工的思维写代码。