zip4cj构建与测试指南:cjpm编译、stdx配置与HLT/LLT/UT三层测试体系
【免费下载链接】zip4cj一个用于创建和解压ZIP压缩格式的库项目地址: https://gitcode.com/Cangjie-TPC/zip4cj
zip4cj 是基于仓颉语言实现的 ZIP 压缩解压缩库,本文带你用 cjpm 一键完成 zip4cj 编译、配置 stdx 依赖路径,并详解 HLT/LLT/UT 三层测试体系如何保障这个压缩库的可靠性——新手也能快速上手。
准备工作:克隆仓库与搭建编译环境
在开始编译 zip4cj 之前,先准备好开发环境:
- 安装仓颉工具链(要求 cjc 1.1.3 及以上版本,与 cjpm.toml 中
cjc-version = "1.1.3"保持一致) - 克隆 zip4cj 源码仓库:
git clone https://gitcode.com/Cangjie-TPC/zip4cj- 了解项目目录结构,这决定了后续编译与测试的操作路径:
├── doc // 设计文档、API文档、LLT覆盖率报告 ├── src // 库源码(crypto加解密、io流、model模型、tasks任务等) │ └── zip_file.cj // 主程序入口类 └── test // 测试用例(HLT、LLT、UT 三层)- src/zip_file.cj 是核心入口类,对外提供压缩、解压、加密等 API
- src/tasks/ 存放压缩、解压、重命名、分包合并等任务实现
- doc/cjcov/ 是 LLT 测试生成的代码覆盖率报告
架构一览:模块化设计让编译与维护更简单
zip4cj 按职责拆分为多个功能包:crypto负责 AES/标准 ZIP 加解密,io处理压缩输入输出流,model定义 ZIP 文件头与参数模型,progress提供进度监控。这种清晰的分包设计让 cjpm 编译时每个模块职责明确,也便于测试体系分层覆盖。
cjpm 编译:stdx 依赖配置是关键
zip4cj 提供两种编译方式,推荐日常使用cjpm 编译:
方式一:cjpm 编译(推荐)
zip4cj 是三方库,依赖仓颉标准扩展库stdx。cjpm 编译前必须完成 stdx 路径配置:
第 1 步:配置 CANGJIE_STDX_PATH 环境变量
获取 stdx 后,将其根目录路径导出为CANGJIE_STDX_PATH。打开 cjpm.toml 可以看到,各平台都通过该变量定位 stdx 动态库:
| 编译目标平台 | stdx 依赖路径 |
|---|---|
| x86_64 Linux | ${CANGJIE_STDX_PATH}/linux_x86_64_llvm/dynamic/stdx |
| aarch64 / x86_64 OHOS | ${CANGJIE_STDX_PATH}/linux_ohos_*_llvm/dynamic/stdx |
| Windows (gnu/mingw32) | ${CANGJIE_STDX_PATH}/windows_x86_64_llvm/dynamic/stdx |
| macOS ARM | ${CANGJIE_STDX_PATH}/darwin_aarch64_cjnative/dynamic/stdx |
第 2 步:执行 cjpm build
cjpm build另外,cjpm.toml 声明了对 zlib4cj 库的 git 依赖(v1.2.0 分支),cjpm 会自动拉取,无需手动处理。
第 3 步:查看编译产物
zip4cj 的output-type配置为dynamic,编译产物为动态库,可被其他仓颉程序直接引用。
方式二:CI 脚本编译(适合持续集成)
如果你需要与官方 CI 流程保持一致,可以下载 TPC-Test-Framework 编译脚本后执行ciTest build完成构建,该脚本会自动处理 stdx 与依赖配置。
编译配置详解:debug 与 release 优化档位
cjpm.toml 的[profile]段为不同场景预设了编译参数,理解它们能让构建更可控:
| 配置项 | 参数 | 说明 |
|---|---|---|
| debug | -g -Woff all | 保留调试符号,关闭全部警告 |
| release | --fast-math -O2 -Woff all | 开启 O2 优化与快速数学运算 |
| build | incremental = true | 启用增量编译,重复构建更快 |
日常开发用 debug 档方便断点调试;发布或性能测试时切换到 release 档,O2 优化对压缩算法的吞吐提升明显。
HLT/LLT/UT 三层测试体系:压缩库质量的三重保障
zip4cj 在 test/ 目录下按仓颉三方库规范组织了三层测试,各层分工明确:
HLT:高层功能测试——验证完整业务场景
HLT(High-Level Test)面向端到端功能,覆盖 doc/feature_api.md 中定义的全部对外 API 场景:
- 文件夹级别压缩 / 解压(含 Zip64 大文件)
- ZIP 内文件重命名、删除、添加
- 分包压缩、分包合并、AES 与 ZIP 标准加密解密
- 子线程压缩与进度监控
一句话概括:HLT 回答"用户用起来对不对"。
LLT:低层测试——代码覆盖率 92% 的底气
LLT(Low-Level Test)贴近源码逻辑逐路径验证,并产出代码覆盖率报告。仓库中的 LLT 覆盖率报告位于 doc/cjcov/index.html,整体覆盖率高达92%,核心文件如 src/ZipFile 相关模块 的覆盖情况可在报告中逐文件查看。
一句话概括:LLT 回答"每行代码跑得对不对"。
UT:单元测试——最小粒度的快速回归
UT(Unit Test)针对工具类与基础方法做最小粒度验证,例如 src/util/crc_util.cj 的 CRC32 校验计算、src/util/bit_utils.cj 的位操作等。UT 用例小而快,适合在每次代码改动后先行执行。
三层测试的分工可以这样记:UT 守函数,LLT 守模块,HLT 守功能。
版本演进:从 0.0.1 到 1.0.7 的里程碑
从 CHANGELOG.md 可以看到清晰的演进路线:0.0.1 奠定文件夹压缩与 Zip64 支持,1.0.0 引入 AES 加密、子线程与进度监控,1.0.7 升级 cjc 至 1.1.3 并修复文件句柄泄漏问题。每个版本的构建与测试均通过 CI 校验(build: pass)。
编译常见问题快速排查 🔧
| 问题现象 | 排查方向 |
|---|---|
| cjpm build 报 stdx 库找不到 | 检查CANGJIE_STDX_PATH是否已导出,且路径下存在对应平台目录 |
| zlib4cj 依赖拉取失败 | 检查网络;zlib4cj 通过 git 依赖自动拉取(v1.2.0 分支) |
| 编译报版本错误 | 确认 cjc 版本 ≥ 1.1.3,与 cjpm.toml 声明一致 |
| OHOS 平台链接失败 | 检查DEVECO_CANGJIE_HOME、DEVECO_OH_NATIVE_HOME环境变量 |
| 测试覆盖率下降 | 运行 LLT 重新生成 doc/cjcov/ 报告并对比 |
小结
| 环节 | 关键命令 / 配置 |
|---|---|
| 环境准备 | 安装 cjc ≥ 1.1.3,克隆仓库 |
| stdx 配置 | 导出CANGJIE_STDX_PATH指向 stdx 根目录 |
| 编译 | cjpm build(或 CI 脚本ciTest build) |
| 测试 | test/目录下 HLT、LLT、UT 三层用例 |
| 覆盖率 | 查看 doc/cjcov/index.html |
掌握 cjpm 编译与 stdx 路径配置后,你可以顺利构建 zip4cj;配合 HLT/LLT/UT 三层测试体系,压缩功能的质量与回归效率都有了完整保障。🚀
【免费下载链接】zip4cj一个用于创建和解压ZIP压缩格式的库项目地址: https://gitcode.com/Cangjie-TPC/zip4cj
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考