Files

T

wandering1 adabb6af12 fix(test): 主机单测/覆盖率产物按工作树分家 + 每次跑独占目录（task-10）

现象（2026-10-25 三条道并行开发实测，看板 task-10）：全量 ci_local 的 L0 里
test-cppcheck / test-coverage 偶发 "files were modified by this hook"，单独重跑
即绿、工作树零改动。根因在 unit_test_harness：obj/exe 直接落在**全机共用**的
%TEMP%，名字由套件名派生（%TEMP%\net_socket_tests.exe、%TEMP%\net_socket_obj），
多棵工作树并行跑同名套件必然互踩。

真正要命的不是编不过，而是**结论张冠李戴**：A 树编译完，B 树把同名 exe 又盖一
遍，A 树随后 subprocess 执行的是 B 树编出来的二进制——两棵树的 summary_marker
一模一样，harness 分辨不出来，于是拿别人的运行结果给自己判 PASS。这种失败不会
变红，只会静默给出错误结论，比红难查一个量级。

修法（不是加锁）：
- 产物根按**工作树**分家：%TEMP%\dtu_host\<仓库根路径 sha1 前 10 位>\。树身份取
  harness 文件自身位置（test/host/common 往上三级），不依赖 cwd/环境变量；工作树
  之间只联接 .venv 与模拟器 SDK，test/host 每棵树各有一份，所以这个身份可靠。
- **每次运行再独占一个子目录** runs\<pid>-<纳秒>\，obj 与 exe 都放进去，跑完
  finally 删（含 Ctrl-C 路径）。这一步顺带把"同树并发同名套件"也消灭了：两个
  进程既拿不到同一个 exe，也拿不到同一个 .obj（实测共享根时并发会因 obj 撞名
  直接编不过，返回 rc=2）。没有牺牲缓存：每个测试单元就一个 .c，cl 每次整体重编，
  "共享 obj 省编译"本来就是错觉。**不加锁**：这里没有需要互斥的独占资源，只是
  名字撞了；加锁等于把 L0.5 变成 build/bench 那样的全局串行。
- 独占目录里留 <exe>.owner.json（suite / repo_root / pid / started）：需要证明"这
  份产物属于哪棵树哪次跑"时有的可查，不必靠时间戳猜。
- 编译返回 0 但产物不存在 → 明确报环境错误，绝不跑来路不明的二进制。
- 两个开关：DTU_HOST_BUILD 改产物根（CI/容器固定路径），DTU_HOST_BUILD_KEEP=1
  保留本次目录（要单步调试 exe 时用）。判据单一事实源 = host_build_root()。
- scripts/check_test_coverage.py 同源改造：work_root 由固定共享名 dtu_test_cov 改为
  复用 harness 的 host_build_root()/coverage，并同步 --work-dir 帮助文案与 docstring
  （docs 里"并行期每人只跑 --module 自己模块"那条规避就此作废，它是为绕开旧共享名
  而写的）。顺带删掉因此不再使用的 import tempfile。

附带修一处同族不诚实（做本任务时从自己的输出里发现）：ci_local 的收尾那行以前
无条件打印"L0 + L0b + L0c + L0.5 全部通过"，--l05-only 时等于把没跑过的段宣布
为通过——正是 A-5 那个"SKIP 冒充 PASS"的镜像版。改为只列本次真正跑过的段。

自证（都是实跑，不是推演）：
- 两棵树身份并发跑同一套件：把修好的 harness 复制成 A/B 两个树身份（repo_root 不
  同 → 两个不同产物根），套件 BUILD 从真仓库加载，各跑 4 轮并发 → 8/8 rc=0，
  两侧 roots 分别是 …\55deb98e3b 与 …\902100bc41，互不可见。
- 敌意场景：把两边 DTU_HOST_BUILD 强行指到同一目录（旧写法必撞 exe/obj）→ 8/8
  rc=0，共享根下只剩一个空的 runs/。同树并发同理被这一条覆盖。
- 单套：test/host/sha256 rc=0（13/13），产物确实落在 …\4b9166f602\runs\<pid>-…；
  覆盖率 --module sha256 rc=0（line=111/114 func=7/7），落在 …\coverage\sha256。
- 全量：ci_local --l05-only → 33 runner(s)，2276/2276 assertions passed，fail=0。
- 临时目录与 scratch 已清理（脚本在仓库外，不入库；ci-artifacts/ 之外无残留）。

文档：test/host/common/README.md 新增"产物目录归属"一节（落点结构、为什么按树、
为什么每次独占、两个开关、一行命令查当前树的产物根）；harness 顶部注释是判据正文。
docs 侧两处按分工归 lead 在 done 时统一改，合并请求里已给可直接粘贴的替换文本：
docs/测试说明/主机单测覆盖率口径.md 的产物目录条与"坑 12"、以及并行任务工作树
方案.md 的产物归属条。AGENTS.md 与 docs/** 本次一个字节没动。

RAM/Flash 增量：0 B（纯测试工具链，不进固件）。gate：见提交钩子输出，未用 --no-verify。
遗留：tools/font_gen/make_font.py 同样用固定共享名（%TEMP%\simsun_regular.ttf、
font_extra_<cp>.c）——同一类跨树竞态，但属道B 字体域，我没动，建议另开一张卡。

2026-10-25 05:13:14 +08:00

6.0 KiB

Raw Blame History

test/host/common/ — 主机侧测试公共库

L0.5 主机侧单元测试的通用 harness：被各模块的单测运行器共享，集中承载工具链探测与编译/运行/判定的公共细节。

文件一览

文件	作用
`unit_test_harness.py`	通用单测 harness（纯标准库）：探测本机 MSVC → 拼 `INCLUDE`/`LIB` → 编译测试单元 → 运行 → 判定退出码

为什么要有这层（2026-10-01 抽取，T-3）

看门狗单测最早的运行器（test/host/watchdog/run_unit_test.py）把工具链探测、 INCLUDE/LIB 拼接、GBK 解码、/wd4819 抑制、退出码契约全写死在模块目录内。第二个 L0.5 单测出现时须整段复制——工具链细节一旦修正（新增 VS 版本、SDK 布局变化、编码处理调整）就会发散。抽取后各模块运行器只剩"声明式"配置。

边界：harness 不认识任何模块——源码路径、桩目录、额外 include、断言汇总行特征全部由调用方传入。新单测只写一个 TestBuild(...) + 一行 sys.exit(...)。

用法（模块侧 `run_unit_test.py` 模板）

import os, sys
HERE = os.path.dirname(os.path.abspath(__file__))
ROOT = os.path.dirname(os.path.dirname(os.path.dirname(HERE)))
sys.path.insert(0, os.path.join(ROOT, "test", "host", "common"))

from unit_test_harness import TestBuild, run_host_unit_test

BUILD = TestBuild(
    name="<模块名> Tests",                       # 人类可读名（打印用）
    src=os.path.join(HERE, "<模块>_test.c"),     # 测试单元（内部 #include 生产源）
    include_dirs=[                               # 顺序敏感：桩目录必须在生产目录之前
        os.path.join(HERE, "stub"),
        os.path.join(ROOT, "App", "util"),
        HERE,
    ],
    summary_marker="=== <模块名> Tests:",          # 运行输出中必须出现的汇总行前缀
)

if __name__ == "__main__":
    sys.exit(run_host_unit_test(BUILD))

另一写法（不落 run_unit_test.py，直接内联）：

from unit_test_harness import TestBuild, run_host_unit_test
raise SystemExit(run_host_unit_test(TestBuild(name="...", src="...", ...)))

退出码契约（各模块运行器统一遵循）

码	含义
`0`	PASS——编译 + 运行成功，且日志含 `summary_marker`
`1`	FAIL——有测试用例未通过
`2`	环境错误——找不到编译器 / 编译失败 / 未产生汇总行

`TestBuild` 字段

字段	必填	说明
`name`	✓	打印用名称；同时用于派生 exe 名与 obj 目录名
`src`	✓	测试单元 `.c` 的绝对路径（内部 `#include` 生产源，保证测的是真代码）
`include_dirs`		`/I` 目录列表；桩目录需排在前面才能覆盖真实头
`summary_marker`		运行输出中必须出现的汇总行前缀；空 = 不校验
`extra_flags`		追加的 `cl.exe` 开关
`exe_name` / `obj_tag`		覆盖派生的产物名 / 中间目录名（默认由 `name` 派生；落点见下节"产物目录归属"）

环境要求

同 L0.5 通用要求（见 ../../../docs/测试说明/测试开发标准流程.md §4.2）： MSVC cl.exe（装了 VS 即有）+ Windows SDK + 纯标准库 Python；不调 vcvars64.bat （内部 reg.exe 受限），直接拼环境变量调 cl.exe。

产物目录归属（跨工作树并行，2026-10-25）

obj / exe / pdb 每次运行独占一个子目录，按工作树分家：

%TEMP%\dtu_host\<仓库根路径 sha1 前 10 位>\runs\<pid>-<纳秒时间戳>\
    <suite>_obj\*.obj        ← 中间目标文件
    <suite>_tests.exe        ← 本次编译产物（跑完随目录一起删）
    <suite>_tests.exe.owner.json  ← 归属凭据：suite / repo_root / pid / started

为什么这么放（两条都是实测出来的，不是洁癖）：

旧写法把 obj/exe 摊在全机共用的 %TEMP%，名字由套件名派生（ %TEMP%\net_socket_tests.exe）。多棵工作树并行跑同名套件就会互相覆盖，而最坏情况不是编不过：A 树编译完，B 树把同名 exe 又盖一遍，A 树随后执行的是 B 树编出来的二进制——两棵树的 summary_marker 一模一样，harness 分辨不出来，等于拿别人的运行结果给自己下结论。2026-10-25 三条道并行时全量 ci_local 里 test-cppcheck / test-coverage 偶发 "files were modified by this hook"、单跑即绿，就是这一类。
按工作树分家 + 每次跑独占同时解决"跨树互踩"和"同树并发"（覆盖率钩子与手工 L0.5 同时跑同一棵树时也会撞）。不牺牲任何东西：每个测试单元就一个 .c，cl 每次整体重编，"共享 obj 省编译"本来就是错觉。没有加锁——这里没有需要互斥的独占资源，只是名字撞了；加锁等于把 L0.5 变成和 build/bench 一样的全局串行。

两个开关（都写在 harness 顶部注释里，判据以 unit_test_harness.host_build_root() 为准）：

DTU_HOST_BUILD=<目录>：改产物根（CI/容器要固定路径时用）。覆盖率侧同源—— scripts/check_test_coverage.py 复用同一个函数，不再用自己那套固定名（旧 %TEMP%\dtu_test_cov 的共享名，正是 docs/测试说明/主机单测覆盖率口径.md 里 "并行期每人只跑 --module 自己模块"那条规避的由来；分家之后该规避不再必要）。
DTU_HOST_BUILD_KEEP=1：保留本次独占目录不删（要单步调试那个 exe 时用，会打印路径）。

想知道当前树算到哪个目录：

& '.venv\Scripts\python.exe' -c "import sys;sys.path.insert(0,'test/host/common');import unit_test_harness as U;print(U.host_build_root())"

⚠️ 注意

本目录在 pre-commit 的 cppcheck / 代码规范排除范围（test/ 豁免）
改动本 harness 会触发 watchdog-unit-test 钩子（files 正则已含本文件）

6.0 KiB Raw Blame History Unescape Escape