ZF sun 336b4d21da test：鸿蒙工程包导出增加产出自检与单元测试 ...

手写 ZIP 编码器的典型 bug 都是静默的 —— 包能生成、看着正常, 但某些机器上
解不开或解出畸形路径。开发期已真实踩过两次(中央目录偏移漏算文件数据长度、
localOffset 记成数据区起点), 两次都只有靠 unzip -t 才发现, 因此加两层保障。

一、脚本内产出自检 (每次导出都跑)
新增 verifyZipFile(), 把写好的 zip 重新解析一遍, 任一项不符直接抛错、不输出
「完成」。刻意用独立解析实现, 不复用写入端逻辑, 避免自证其说:
- EOCD / 中央目录: 签名、条目数、偏移与长度边界一致
- localOffset: 每条必须真的指向本地文件头, 且文件名与中央目录一致
- CRC: 逐条解压后重算 CRC32 比对
- 条目名: 必须正斜杠、必须置 UTF-8 标志位、必须可逆解码为合法 UTF-8
- 内容断言: 必需文件齐全; node_modules/build/.preview 等排除项不得混入

二、单元测试 tests/pack-harmony-project.test.js (16 条)
正向用例写夹具目录打包再独立解析还原, 校验内容/目录/中文名/零字节/空目录/
可压缩与不可压缩内容; 反向用例故意篡改 zip 断言自检能抓到 —— 反向用例一旦
失效自检就形同虚设, 故必须保持通过。

过程中自检抓到自身一条误判: 排除校验原先用子串匹配, 把合法源码
entry/src/ohosTest/ets/test/Ability.test.ets 当成 .test 构建产物。已改为按
路径分段精确匹配, 并加了一条反向用例锁定。

同时修掉两个隐患: stats 是模块级累加器(同进程重复调用会翻倍), main() 原先
无条件执行(require 脚本就会跑一遍打包), 现加 require.main 守卫并导出内部
实现供测试使用。

已验证: 本测试文件 16/16 通过, npm test 全量 17 个测试文件通过, 实打包
2.99MiB 包自检通过且 unzip -t 交叉验证无错误。

2026-10-17 14:42:28 +08:00

16 KiB

Raw Blame History

View Raw