新闻详情

新闻详情

首页 / 资讯中心 / 详情

hg-git插件开发与测试完全指南:Mercurial标准.t测试套件实战

发布时间:2026/8/26 20:07:00
hg-git插件开发与测试完全指南:Mercurial标准.t测试套件实战
hg-git插件开发与测试完全指南Mercurial标准.t测试套件实战【免费下载链接】hg-gitmercurial to git bridge, pushed to directly from the hg-git plugin in Hg项目地址: https://gitcode.com/gh_mirrors/hg/hg-githg-git 是一款让 Mercurial 与 Git 仓库无缝互通的桥接插件它让 Hg 用户可以直接向 Git 服务器推送、拉取代码且转换过程无损。本文带你实战 hg-git 的插件开发与测试看懂它的 Mercurial 标准.t测试套件如何组织、运行与扩展并掌握从run-tests.py到testutil的完整测试工作流。一、为什么 hg-git 的测试值得学hg-git 的核心设计是无损双向同步所有数据以 Hg 原生格式存储Git 目录只是一份可重建的缓存详见 DESIGN.txt。这种翻译层最容易在边缘场景出 bug——标签、分支、书签、子模块、编码……所以项目用30 个.t测试脚本覆盖了几乎所有同步路径。这些测试采用的是Mercurial 官方标准的测试格式TAP 风格的 shell 脚本学会它等于同时学会了给 Mercurial 核心及任何扩展写测试的方法。二、测试目录结构速览打开tests/目录每个文件各司其职文件/目录作用tests/run-tests.py测试运行器驱动、比对、并行、跳过、超时处理tests/testutil公共测试逻辑固定时间的提交函数、依赖检查tests/hghave.py特性探测判断环境是否有 git、dulwich 等依赖tests/heredoctest.py执行.t文件中内嵌的 Python 代码块test-*.t如 tests/test-clone.t、tests/test-push.t一个个具体的场景测试脚本测试场景覆盖得很全克隆与拉取tests/test-clone.t、tests/test-pull.t、tests/test-git-clone.t推送与分支tests/test-push.t、tests/test-bookmark-workflow.t合并与冲突tests/test-merge.t、tests/test-conflict-1.t、tests/test-octopus.t标签与编码tests/test-git-tags.t、tests/test-encoding.t边缘场景tests/test-empty-working-tree.t、tests/test-illegal-contents.t、tests/test-subrepos.t三、最快启动方式一键运行测试套件项目根目录的 Makefile 提供了现成的入口只需 3 个目标make tests # 运行全部 .t 测试 make test-clone # 只跑指定测试自动加 test- 前缀如 test-push.t make all-version-tests # 跨多个 Mercurial 版本回归测试其中make test-clone本质是执行cd tests python run-tests.py --with-hgwhich hg test-clone而run-tests.py还有一组高频调试参数在 tests/run-tests.py 的parseargs()中定义参数用途-d/--debug实时输出测试脚本内容逐行排查-i/--interactive输出变化时交互确认用于更新期望输出-j2并行跑 2 个任务加速大套件-r/--retest只重跑上次失败的测试-f/--first首个失败即退出--time输出每个测试的耗时排行 新手建议先用make test-clone跑通单个测试再用-d观察它内部到底执行了什么。四、解剖一个 .t 测试文件以 test-clone.t 为例.t文件的语法极其简洁——缩进 2 空格 $表示要执行的命令缩进 2 空格的裸文本表示期望输出。以 tests/test-clone.t 为例Load commonly used test logic $ . $TESTDIR/testutil $ git init gitrepo Initialized empty Git repository in $TESTTMP/gitrepo/.git/ clone a tag $ hg clone -r alpha gitrepo hgrepo-a | grep -v ^updating importing git objects into hg 1 files updated, 0 files merged, 0 files removed, 0 files unresolved读懂它只需掌握 4 个约定$TESTTMP每个测试都运行在独立临时目录中避免互相污染$TESTDIR测试文件所在目录用来加载公共逻辑注释行就是标题顶格写的文字如clone a tag在 diff 报告里充当段落标题帮你快速定位失败位置$HGPORT等占位符运行器会把真实端口号、临时路径自动替换让期望输出保持稳定。对比 tests/test-push.t 可以看到完整闭环Git 端建库 → Hg 克隆 → Hg 端提交推送 → 回 Git 端用git branch -v验证分支是否如预期出现beta、master分列两边——一端写入、另一端断言就是 hg-git 测试的黄金套路。五、testutil让测试确定性的秘密武器 任何测试最大的敌人是每次输出都不一样。tests/testutil 用三招彻底解决① 固定提交者身份导出GIT_AUTHOR_NAMEtest、GIT_AUTHOR_EMAILtestexample.org两端日志永远一致。② 固定时间戳fn_git_commit和fn_hg_commit两个 shell 函数从2007-01-01 00:00:10开始逐秒递增提交时间——所以你会在所有测试里看到同一天的日期却从不出错。③ 依赖前置检查testutil 顶部会检查dulwich是否可导入、git客户端是否存在缺失时以退出码 80 优雅跳过skipped而不是报一堆莫名其妙的失败。六、hghave优雅跳过不支持环境的测试tests/hghave.py 提供了一组特性探测函数.t文件里可以用条件块按环境裁剪#if git $ git --version #endifhghave.py的checks字典注册了 30 种能力检测git、ssl、symlink、unix-permissions……每个都配了人类可读的描述。这样同一份测试文件能在 Linux、macOS、Windows 上各跑各的子集报告里清楚地告诉你为什么跳过。七、贡献一个新测试4 步走 ✅项目的 CONTRIBUTING 明确了硬性门槛提交补丁前测试套件必须通过。流程如下复制模板找个相近的现有文件比如推送相关就参考 tests/test-push.t改名复制保留开头的$ . $TESTDIR/testutil写场景按$ 命令 期望输出的格式写步骤注意所有提交都用fn_hg_commit/fn_git_commit保证确定性首跑捕获输出先随便填期望输出跑一遍用run-tests.py -i交互式接受实际输出再用--retest只复查该文件自检确认输出里没有残留$TESTTMP外的随机信息端口、路径、时间戳再跑一次全量make tests收尾。八、常见问题清单Q1测试全部显示 skipped 怎么办多半是环境缺dulwich或git客户端。testutil 检查不通过就会以skipped: missing feature退出先装好依赖再谈别的。Q2make tests和我直接跑run-tests.py有什么区别没有本质区别Makefile 只是帮你拼好了--with-hgwhich hg 参数你也可以从 Mercurial 源码树里调用run-tests.pyDESIGN.txt 中有说明以便测试不同的 Hg 版本。Q3输出对不上diff 里全是时间戳检查你是不是绕过了 testutil 的提交函数、直接用了hg commit——没有固定时间戳每次比对必然失败。总结hg-git 的测试体系是小而美的典范run-tests.py管执行、testutil管确定性、hghave管环境、.t文件管场景四者各司其职。无论是给这个 Mercurial-Git 桥接插件提补丁还是为自己的 Hg 扩展写测试这套模式都能直接照搬。跑通make tests看到0 failed的那一刻就是你入门贡献的最佳起点。【免费下载链接】hg-gitmercurial to git bridge, pushed to directly from the hg-git plugin in Hg项目地址: https://gitcode.com/gh_mirrors/hg/hg-git创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
网站建设 高端定制 企业官网