test

命令: /ea test (测试生成与执行)

功能

测试双产出：每个测试都生成「测试用例文档 + 可运行测试代码」。

• unit：纯函数 host 单元测试（轻量自研：桩函数 + 断言 + main，零框架依赖）
• board：板级工装验收测试（用例文档 + 板载测试固件/驱动脚本）

触发

/ea test unit <文件>               # 对指定 .c 文件的纯函数生成单测
/ea test board <功能描述>          # 对功能/需求生成板级工装用例

⚠️ unit 只收 1 个位置参数（target）。写 /ea test unit <文件> <函数名> 会 error: unrecognized arguments —— 工具没有筛选函数名的参数。要只测某个函数，先跑一次 拿到「候选函数」列表，生成后在 .c 里删掉其余用例即可。

单元测试（unit）

流程

1. 【读 context】 确认工程上下文
2. 【扫描目标】 tools/test-runner/scripts/test_gen.py unit <文件> 提取函数签名，识别纯函数（无硬件外设调用）
3. 【生成双产出】 写入 <STATE_DIR>/tests/unit/：
   • 测试代码 <name>.c：桩函数（mock GPIO_SetBits/USART_SendData 等硬件调用）+ 断言测试体 + main runner
   • 测试用例文档 <name>.md：用例ID / 输入 / 预期输出 / 覆盖点
4. 【补全骨架】 ⚠️ 这一步不能跳 —— 见下「生成的骨架必然编译不过」
5. 【host 编译运行】 补全后再编译（Windows 用 mingw gcc；也可用 arm-none-eabi-gcc）
6. 【输出结果】 每个用例 PASS/FAIL

⚠️ 生成的骨架必然编译不过 —— 它是半成品，不是成品

test_gen.py 产出的是待补全的骨架：它只认函数名，不解析签名，所以断言一律写成 f(0)。拿未经补全的产物直接 --cc gcc 必然失败，这是预期行为，不是工具坏了：

现象	原因
implicit declaration of 'X'	骨架把原型声明写成了注释（/* int target_func(int a, int b); */），等你替换
too few arguments to function 'X'	实参一律按 f(0) 生成，无视真实签名（3 个形参也只给 1 个实参）
void value not ignored	void 函数也被套进了 ASSERT_EQ(...)
fatal error: XXX.h: No such file	编译命令不带 -I，头文件搜索路径不从 .uvprojx 继承
undefined reference	--cc gcc 只编译生成的 .c，未链接被测源；且 static 函数跨 TU 本就链不上

补全清单（AI 按需求逐项做，做完再编译）：

1. 换成真实的 #include 与函数原型声明（骨架里是注释）
2. 按真实签名填实参，void 函数改用 ASSERT_TRUE 或直接调用
3. 补 -I <头文件目录>，并把被测 .c 一起编译；static 函数改为在骨架中 #include 被测源
4. 逐个核对 /* TODO: 核对输入/预期 */，给出真实输入与预期输出

调用方式

# 生成（不编译）
python <SKILL>/tools/test-runner/scripts/test_gen.py unit <目标.c>
# 产物: <STATE_DIR>/tests/unit/<name>.c + <name>.md

# 补全骨架后再编译运行（示例：头文件目录 + 被测源一并给上）
gcc <STATE_DIR>/tests/unit/<name>.c <被测源.c> -I <头文件目录> -o /tmp/ut && /tmp/ut

硬件耦合处理

• 目标函数直接调用硬件寄存器/外设库且无法桩化 → 提示「该逻辑适合板级测试」→ 走 board
• 测试代码中桩函数与真实实现冲突时，用 #ifdef EA_TEST 包裹被测模块