Uni-Mol Tools CLI 测试套件完整解读67 项测试全量通过背后的架构设计与质量保障【免费下载链接】CLI-AnythingCLI-Anything: Making ALL Software Agent-Native -- CLI-Hub: https://clianything.cc/项目地址: https://gitcode.com/GitHub_Trending/cl/CLI-Anything导读本文基于 CLI-Anything 仓库中unimol_toolsAgent Harness 的官方测试报告 TEST_REPORT.md系统拆解 Uni-Mol Tools CLI 测试套件的整体设计67 项单元测试如何覆盖存储分析、模型管理、清理操作与项目管理四大核心模块实现约 95% 的行覆盖率与 100% 通过率。读者将掌握该测试套件的文件结构、运行方式、CI/CD 集成方案并深入理解每个被测 API 的底层实现逻辑AUC 评分算法、存储分析流程、删除策略等可作为分子性质预测工具链质量保障与二次开发的实战参考。一、测试套件全景67 项测试的布局与分工该测试套件部署在unimol_tools/agent-harness/cli_anything/unimol_tools/tests/目录下围绕核心业务模块core/包划分出 4 个测试文件。测试对象与业务模块的对应关系如下测试文件被测模块测试数量覆盖范围test_storage.pycore/storage.py20存储分析与格式化test_models_manager.pycore/models_manager.py35模型评分、排序、对比与历史test_cleanup.pycore/cleanup.py8模型删除与批量清理test_core.pycore/project.py4项目创建、加载与数据集配置合计67 项测试全部通过100%覆盖了训练 → 预测 → 模型管理核心工作流中除端到端集成之外的全部逻辑层。测试依赖统一由 conftest.py 提供 fixture包括数据 fixture基于 6 条 SMILES 基础分子重复 10 次得到 60 样本的分类/回归/多标签数据集classification_data、regression_data、multiclass_data、multilabel_classification_data、multilabel_regression_data等并为回归与多标签任务生成临时 CSV 文件临时目录 fixturetmp_dir与tmp_path保证测试隔离不污染真实项目CLI 解析辅助_resolve_cli()优先查找已安装命令否则回退到python -m cli_anything.unimol_tools的开发模式并通过CLI_ANYTHING_FORCE_INSTALLED1环境变量强制使用已安装版本。二、存储分析模块测试20/20test_storage.py存储分析是 Uni-Mol 项目长期运行的磁盘体检功能。它递归扫描项目目录中的三类数据模型、构象、预测结果输出可读的容量报告与清理建议。test_storage.py的 20 项测试覆盖了从底层工具函数到上层分析接口的完整链路。2.1 容量格式化format_sizeformat_size将字节数转换为人类可读形式按B → KB → MB → GB → TB依次除以 1024输出保留一位小数for unit in [B, KB, MB, GB, TB]: if bytes_size 1024.0: return f{bytes_size:.1f}{unit} bytes_size / 1024.0 return f{bytes_size:.1f}PB对应测试逐级验证了512.0B、1.0KB、1.5KB、1.0MB、2.5MB、1.0GB以及0.0B零字节边界的格式化结果。该函数的实现位于 storage.py。2.2 递归目录大小计算get_directory_sizeget_directory_size基于os.walk递归遍历目录对每个文件调用get_file_size内部对不存在的文件或权限错误返回 0求和for dirpath, dirnames, filenames in os.walk(path): for filename in filenames: filepath os.path.join(dirpath, filename) total get_file_size(filepath)测试验证了空目录返回 0、单文件目录精确统计10240 字节、嵌套目录正确累加5000 3000 8000、以及不存在目录返回 0 的容错行为。get_file_age_days则基于文件mtime计算文件年龄用于后续的过期模型检测。2.3 项目级存储分析analyze_project_storage这是存储模块的核心入口返回结构如下该结构也被报告列为 API 对齐的关键改动点{ total_mb: float, breakdown: { models: float, conformers: float, predictions: float, models_pct: float, conformers_pct: float, predictions_pct: float }, models_detail: [{run_id, size_mb, auc, age_days}, ...], recommendations: [...] }分析流程分三步扫描实验目录遍历project[runs]通过run.get(model_dir) or run.get(save_path)兼容两种字段命名对每个模型目录计算大小与年龄写入models_detail扫描构象与预测目录分别统计项目根下的conformers/与predictions/目录生成建议内置两条启发式规则——模型年龄大于 7 天触发old_models建议附带可节省空间估算potential_savings_mbAUC 低于 0.75 且年龄大于 1 天触发low_performance建议。test_storage.py通过mock_project_dirfixture 构造了 100MB 150MB 两个模型、10MB 构象与预测文件的真实目录结构验证基础分析结果字段完整、total_mb 0、百分比总和约等于 100允许浮点误差、models_detail条数正确、构象检测生效test_old_models_recommendation将时间戳改为 10 天前后断言生成了清理建议。边界测试覆盖了缺失project_root、指向不存在路径、缺失runs字段三种场景均优雅降级为 0 而不抛异常。三、模型管理模块测试35/35test_models_manager.py模型管理是整个套件中测试量最大的模块35 项对应 models_manager.py 的 6 个核心函数代码覆盖率约 98%。3.1 评分算法calculate_model_scoreAUC 驱动的 0–10 分制评分算法采用100% AUC 基score AUC × 10同时支持通过权重参数叠加训练时长与时间新鲜度两个可选的辅助维度AUC 维度权重weight_auc默认 1.0优先取metrics[auc]缺失时回退metrics[auroc]再缺失回退 0.5然后auc * 10映射到 0–10时间维度权重weight_time默认 0.0假设典型训练时长 10–30 秒按max(0, min(10, (30 - duration) / 2))反比折算越快越高分新鲜度维度权重weight_recency默认 0.024 小时内 10 分超过 7 天为 0 分中间线性递减无时间戳时取中性分 5。测试用例逐一断言AUC 0.85 → 8.5 分、AUC 1.0 → 10.0 分、AUC 0.5 → 5.0 分、缺失auc时回退auroc得 8.8 分、缺失全部指标时默认 0.5 AUC 得 5.0 分以及自定义权重weight_auc0.7, weight_time0.3下的分数变化。边界测试验证了非法时间戳与负duration_sec均不会导致崩溃。3.2 模型排序rank_models与状态标签rank_models对项目内所有 run 计算分数并按降序排列附加顺序rank从 1 开始同时根据 AUC 与分数赋予状态标签AUC 区间状态标签判定条件≥ 0.85Best/Good分数 ≥ 8.5 为 Best否则 Good≥ 0.75Ok—≥ 0.65Weak— 0.65Poor—sample_runsfixture 提供 4 个不同性能的 runAUC 0.92/0.85/0.75/0.68测试验证了排序结果run_003 → run_002 → run_001 → run_004、每个元素包含score/auc/status/rank字段、rank 连续编号以及空项目返回[]、单 run 场景 rank1。3.3 最佳模型选择get_best_modelget_best_model将 run 分为含指定指标与不含指标两组只要存在带指标默认auc的 run 就取指标最大者若全部缺失则回退返回第一个 run这是报告中明确修复的边界行为。测试覆盖了按 AUC 与按 accuracy 选取、空项目返回None、指标全缺失时仍返回 run 三种情况。3.4 多模型对比compare_modelscompare_models支持对 ≥ 2 个模型进行多指标横向对比内置指标清单auc, auroc, accuracy, acc, precision, recall, f1_score, mcc, log_loss并额外对比training_time。判定规则为大多数指标取最大值log_loss与训练时长取最小值越小越好最终通过各模型赢得指标次数win_counts决出overall_winner。测试验证了字段完整性、指标不足时返回错误信息Need at least 2 models to compare、不存在的 run 报错以及三模型对比中run_003赢得最多指标。3.5 性能历史与趋势get_model_historyget_model_history按时间戳排序生成timeline含每个 run 的 AUC 与时长并基于首尾 AUC 差判定趋势末次 AUC − 首次 AUC 0.05→improving末次 AUC − 首次 AUC −0.05→declining否则 →stablerun 数不足 2 时 →insufficient_data空项目 →none并返回total_runs: 0这是报告记录的修复点之一。同时生成洞察insights最佳模型、改进/下降趋势提示以及 run ≥ 3 时最近一次 AUC 下滑超 0.02 的警告。测试分别构造了递增0.70→0.90、递减0.90→0.70与基本持平0.80→0.82三组数据断言趋势判定正确。3.6 可删除模型建议suggest_deletable_models该函数是模型治理的决策引擎参数与默认值为keep_best_n3保留前 N 佳、min_auc0.75最低保留 AUC、max_age_days7保留近期模型的最长天数。决策逻辑按优先级综合评分前 N 名 →永远保留keep注明排名年龄 ≤max_age_days的近期模型 → 保留年龄超标且 AUC min_auc→ 建议删除delete年龄超标但性能尚可 → 归档archive。测试验证了默认参数下三个列表齐全、keep_best_n3时至少保留 3 个、min_auc0.80时删除列表中的模型 AUC 均低于阈值、max_age_days2时近期模型被保留以及空项目返回全空列表。四、清理操作模块测试8/8test_cleanup.py清理模块在本次测试体系建设中经历了从复杂到精简的重构原实现的archive_modeltar.gz 归档、restore_model从归档恢复、压缩率跟踪与归档文件管理等非核心功能被移除测试相应从 28 项缩减到 8 项只保留训练/预测主流程必需的删除能力。这一决策使模块行覆盖率达约 90%同时显著降低维护成本——报告对此的总结是这些特性增加了复杂度但对核心工作流train → predict → manage models并非关键。4.1 单模型删除delete_model删除前计算目录大小并展示确认信息confirmTrue时交互式询问yes/noconfirmFalse则直接执行shutil.rmtree删除目录并从project[runs]中移除对应记录成功返回True模型不存在或目录缺失返回False。测试断言了删除后目录不存在、run 列表长度减 1 且不再包含该 run、以及删除不存在的 run 返回False。4.2 批量清理batch_cleanupbatch_cleanup对delete_ids列表逐个执行删除内部统一confirmFalse避免重复交互统计成功/失败列表并累加释放空间输出space_freed_mbarchive_ids参数仅为向后兼容保留简版中不支持归档。测试覆盖了批量删除两个模型、混入不存在 run 时进入failed列表、以及space_freed_mb 0的释放空间计算。4.3 归档列表list_archiveslist_archives扫描归档目录默认~/.unimol-archive/中的.tar.gz文件并解析文件名项目名_runid_日期.tar.gz按修改时间倒序返回目录不存在或为空时返回[]。测试验证了这两种容错路径。五、项目核心模块测试4/4test_core.pytest_core.py对 project.py 进行最小化冒烟测试验证项目生命周期的三个基本能力创建项目create_project断言返回status created、路径以project.json结尾、JSON 中project_type与config.model_name正确。创建时会按任务类型自动设定默认指标分类 →auc多分类 →acc回归/多标签回归 →mae并初始化experiments/、conformers/、predictions/目录结构加载项目load_project不存在的路径抛出FileNotFoundError数据集配置set_dataset合法类型train/valid/test更新路径并返回status updated非法类型抛出ValueError(Invalid dataset type)。六、测试运行方式与 CI/CD 集成6.1 统一入口run_tests.sh仓库提供了封装脚本 run_tests.sh它自动完成pytest存在性检查缺失时提示安装pytest pytest-cov pytest-xdist、参数解析与 pytest 命令组装参数作用--unit仅运行 4 个单元测试文件默认--integration仅运行标记为integration的测试如test_all_tasks.py--all同时运行单元与集成测试--coverage生成覆盖率报告--covcli_anything.unimol_tools.core输出 HTML 与终端摘要-v/--verbose详细输出--parallel使用-n autopytest-xdist并行加速常用命令# 从仓库根目录运行全部单元测试详细模式 bash unimol_tools/agent-harness/docs/test/run_tests.sh --unit -v # 附带覆盖率报告 bash unimol_tools/agent-harness/docs/test/run_tests.sh --unit --coverage # 并行运行以加速 bash unimol_tools/agent-harness/docs/test/run_tests.sh --unit --parallel6.2 直接调用 pytest如需精确控制测试范围可直接指定测试文件# 存储模块 pytest unimol_tools/agent-harness/cli_anything/unimol_tools/tests/test_storage.py -v # 模型管理模块 pytest unimol_tools/agent-harness/cli_anything/unimol_tools/tests/test_models_manager.py -v # 清理模块 pytest unimol_tools/agent-harness/cli_anything/unimol_tools/tests/test_cleanup.py -v # 全部单元测试 pytest unimol_tools/agent-harness/cli_anything/unimol_tools/tests/ -v6.3 三层次质量门禁报告给出了把测试嵌入日常开发流的三种做法CI/CD在 GitHub Actions workflow 中配置on: [push, pull_request]运行bash run_tests.sh --unit --coverage作为每次提交的质量门禁Pre-commit Hook在.git/hooks/pre-commit中执行bash run_tests.sh --unit失败则中断提交本地开发提交前快速检查bash run_tests.sh --unit完整检查加--coverage并可用ptwpytest-watch进入监听模式持续反馈。七、覆盖率分析与质量结论7.1 模块覆盖率一览模块被测代码行数覆盖率结论storage.py~100~95%优秀models_manager.py~400~98%优秀cleanup.py~100~90%优秀整体~600~95%生产就绪7.2 已覆盖与刻意未覆盖已覆盖项目创建与管理、存储分析与建议、模型排序与对比、性能趋势分析、模型清理与删除等核心工作流缺失文件/目录、非法参数、空项目、畸形数据等边界不存在的模型、缺失指标、权限错误等异常路径。刻意未覆盖移除的非核心功能模型归档/压缩、模型恢复、归档管理。留作未来工作低优先级端到端训练工作流、CLI 命令执行、多项目场景等集成测试以及大数据集处理、内存占用剖析、并发操作等性能测试。7.3 报告揭示的工程价值从源码与测试的对照关系可以确认本次测试体系建设带来的实际收益包括API 一致性收敛storage.py将返回值从total_size字节改为total_mb浮点 MB、扁平化breakdown结构、新增models_detail数组、兼容model_dir与save_path双字段——这些调整都直接反映在analyze_project_storage的 docstring 与返回结构注释中见 storage.py边界行为修复get_model_history补充total_runs字段get_best_model在无有效指标时回退到首个 rundelete_model简化返回布尔值并统一支持confirm参数架构做减法砍掉归档/恢复这类非核心复杂度使代码库更易维护测试也从 28 项收敛到 8 项而不损失主流程保障。八、后续维护建议低优先级报告列出的可持续改进方向包括补充端到端训练流程、CLI 命令执行与多项目场景的集成测试覆盖大文件处理与并发操作的压力测试验证文档字符串中的示例代码与教程代码。维护纪律上建议每次发布前运行测试、随功能演进更新 fixture、新功能配套新增测试并长期维持 85% 以上的覆盖率基线、及时跟进失败用例。测试套件版本1.0 |测试总数67通过率 100% |整体覆盖率约 95% |状态全部通过、生产就绪核心实现与测试文件速查storage.py、models_manager.py、cleanup.py、project.py、test_storage.py、test_models_manager.py、test_cleanup.py、test_core.py、conftest.py、run_tests.sh【免费下载链接】CLI-AnythingCLI-Anything: Making ALL Software Agent-Native -- CLI-Hub: https://clianything.cc/项目地址: https://gitcode.com/GitHub_Trending/cl/CLI-Anything创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
