这一章我们将切入一个非常关键且具有挑战性的场景：OTA（Over-the-Air）固件更新。
OTA 逻辑最怕的是什么？是中途断电、Flash 写入失败、校验和不匹配。如果你在真机上测试这些异常，可能需要反复烧录、断开电源，甚至不小心把片子变"砖"。在 TDD 的世界里，我们可以优雅地模拟这些灾难。
9.1 OTA 测试的痛点
-
硬件寿命：频繁擦写内部 Flash 也是有寿命限制的。
-
场景模拟：你很难手动模拟"在写入第 1024 个字节时突然断电"。
-
复杂校验：CRC32、SHA256 的验证在 PC 上跑比在 MCU 上快得多。
9.2 接口抽象：Storage_Interface.h
为了让 OTA 逻辑可测，我们必须隔离 STM32 的 HAL_FLASH_Program。
// Storage_Interface.h
#ifndef STORAGE_INTERFACE_H
#define STORAGE_INTERFACE_H
#include <stdint.h>
#include <stdbool.h>
typedef enum { FLASH_OK, FLASH_ERROR, FLASH_BUSY } FlashStatus_t;
FlashStatus_t HW_Flash_ErasePage(uint32_t page_addr);
FlashStatus_t HW_Flash_Write(uint32_t addr, uint8_t* data, uint32_t len);
void HW_System_Reset(void);
#endif
9.3 实战：测试"断点续传"逻辑
我们要实现一个 OTA 接收器：它按包接收固件，记录已写入的偏移量，如果写入失败要能重试。
编写测试 (test_Ota_Service.c)： 我们要模拟一个非常极端的情况：第一次写入成功，第二次写入失败。
#include "unity.h"
#include "mock_Storage_Interface.h"
#include "Ota_Service.h"
void test_Ota_Should_HandleFlashWriteFailure(void) {
uint8_t dummy_data128 = {0xA5};
// 1. 模拟第一包数据写入：返回成功
HW_Flash_Write_ExpectAndReturn(0x08010000, dummy_data, 128, FLASH_OK);
bool result = Ota_ProcessPacket(0, dummy_data, 128);
TEST_ASSERT_TRUE(result);
// 2. 模拟第二包数据写入：硬件突然报错（比如电压不稳或页损坏）
HW_Flash_Write_ExpectAndReturn(0x08010080, dummy_data, 128, FLASH_ERROR);
result = Ota_ProcessPacket(128, dummy_data, 128);
// 验证：逻辑层应该识别出失败，并返回 false，以便触发重传机制
TEST_ASSERT_FALSE(result);
}
9.4 进阶技巧：模拟"脏数据"与校验失败
在 OTA 中，校验和（Checksum）是最后一道防线。
void test_Ota_Should_RejectFirmware_WhenChecksumMismatch(void) {
// 模拟 Flash 读取出的数据
// 我们不需要真的读 Flash，直接 Mock 掉读取函数返回"坏数据"
HW_Flash_Read_StubWithCallback(my_Fake_Flash_Read_Bad_Data);
// 执行校验逻辑
bool is_valid = Ota_VerifyChecksum();
// 验证：校验不通过，且绝不调用系统重启去运行坏固件
TEST_ASSERT_FALSE(is_valid);
// 确保没有误触发系统重启（这也是一种验证）
HW_System_Reset_Expect(); // 如果你预期它报错后重启到 Bootloader
}
9.5 本章核心：防御式编程：
-
状态机保护：OTA 过程中如果收到无关的串口命令，状态机是否会崩溃？
-
原子操作模拟：模拟擦除了一半突然断电，Bootloader 能否识别出固件不完整？
-
边界检查：Mock 掉 Flash 大小接口，验证如果固件包超过 Flash 容量，代码是否会越界写入。
本章小结
这一章证明了 TDD 不仅能测"好用"的情况，更能测"坏掉"的情况。对于 OTA 这种高风险模块，这种"离线异常注入"是保证产品不批量变砖的唯一手段。