如何在提交 PR 前用 v test-all 在本地运行 V 语言完整测试套件【免费下载链接】vSimple, fast, safe, compiled language for developing maintainable software. Compiles itself in 1s with zero library dependencies. Supports automatic C V translation. https://vlang.io项目地址: https://gitcode.com/GitHub_Trending/v/v给 V 仓库贡献代码改编译器、修 vlib bug时TESTS.md给出的明确要求是在本地完成改动之后、提交 PR 之前先跑一遍v test-all。它的定位是测试并构建所有内容Test and build everything用来在本地验证 CI 大概率会通过——这是所有测试入口中最慢、但覆盖最全的一条。本文按准备环境 → 跑完整套件 → 失败时定位的顺序说明完整流程。准备工作克隆仓库并确保有一个可用的编译器将 V 仓库克隆到本地目录例如命名为nvcd进入仓库顶层即包含.git的目录。CONTRIBUTING.md中示例使用--depth1的浅克隆。确保手头有一个可工作的 V 编译器。如果编译器坏了可以运行makeWindows 上为makev.bat它会下载 C 版本的编译器并从头重建。一个CONTRIBUTING.md明确提醒的坑如果你的改动引入了 breaking change 并执行了v self用 V 源码重建 V 编译器新编译器可能无法再构建自身。因此建议保留一份可工作的编译器可执行文件的备份再开始实验性改动。可选安装 pre-commit 钩子让每次 commit 前自动格式化代码。需要在仓库顶层目录执行cp cmd/tools/git_pre_commit_hook.vsh .git/hooks/pre-commit chmod 755 .git/hooks/pre-commit这一步是可选的如果不装提交前需要手动跑v fmt -w 你修改的文件详见下文提交前检查。运行完整测试套件v test-all在仓库顶层目录执行v test-all按TESTS.md的说明它会依次执行以下子步骤顺序命令作用1v test-cleancode检查大部分.v文件在v fmt运行后保持不变2v test-self运行 vlib 模块测试包括编译器测试3v test-fmt检查当前目录下的.v文件都已经是格式化后的状态4v build-tools测试构建 V 工具5v build-examples测试构建examples/下的 V 程序6v check-md -hide-warnings .检查所有.md文件格式正确且其中 V 代码块示例可以编译/格式化7v install nedpals.args安装第三方模块验证安装流程成功判定TESTS.md将v test-all描述为 Useful to verify locally, that the CI will most likely pass用于本地验证 CI 大概率会通过。整套子步骤都无错误跑完即可进入提交流程任何一步失败都会中断并暴露问题需要先修好再提 PR。官方提速建议TESTS.md明确提示编译测试时可用v -cc tcc因为 TCC 比 clang/gcc/msvc 等 C 编译器快得多——测试命令内部会多次数百乃至数千次调用 V 编译器C 编译器速度直接影响总耗时。失败时如何定位逐个重跑子步骤v test-all是串联执行失败时先看输出停在哪个子命令然后单独重跑该命令缩小范围v test-cleancode v test-self v test-fmt v build-tools v build-examples v check-md -hide-warnings .针对.v测试文件所有test_开头的函数会被 V 测试框架自动执行TESTS.md给出了更细粒度的运行方式# 运行单个测试文件所有断言都通过时退出码为 0 v file_test.v # 同上并输出每个 test_ 函数的耗时报告 v -stats file_test.v # 递归运行 folder 下所有 _test.v 文件默认最多 4 个并行 worker v test folder # 同上附耗时报告 v -stats test folder两个影响并行度的要点默认情况下v test最多使用 4 个并行 worker并按每 8 GiB 内存分配一个 worker在 Linux 上取物理内存与活动 cgroup 内存限制中较小者。如果你的测试负载和机器配置已知可以把环境变量VJOBS设为正整数来显式指定 worker 数量。常见的两类失败及文档给出的修复命令Markdown 格式检查失败check-md报格式错误# 二选一 v check-md -fix file.md VAUTOFIX1 ./v check-md file.md源码未格式化test-cleancode/test-fmt失败提交前对改动过的文件运行v fmt -w 你修改的文件如果改的是 Markdown.md文件提交前单独检查v check-md 你修改的 .md 文件限制与边界v test-all是最慢的测试入口文档同时称其most comprehensive覆盖最全它不是每个小改动都必须跑的最小集而是提交 PR 前的完整验证。如果改动引入 breaking change先备份可工作的编译器可执行文件再重建 V否则可能失去自举能力。主仓库 CITESTS.md中对.github/workflows/ci.yml的描述除自测试外还会跑v vet vlib/vstyle checker以及多种编译模式下的v test-self。本地test-all覆盖的是其中最主要的部分但个别 CI 专属任务如 sanitizer、valgrind见 ci/linux_ci.vsh 中的任务定义不在test-all范围内。可选分支ci/qemu_linux_tests.sh 会把当前 checkout 同步到一个已预建的 Debian ARM64 QEMU 虚拟机中重建 V 并运行测试套件不带 V 参数时默认执行的正是test-all。该脚本要求qemu-system-aarch64、rsync 和预先创建的 VM 资产磁盘、SSH key 等只适用于已有该虚拟机环境的场景。验证完成后的下一步v test-all全部通过后按CONTRIBUTING.md的示例工作流推送改动到你的 forkgit push pullrequest或通过hub pull-request发起 PR。PR 合并前如果 CI 仍有失败查看失败任务的 URL 找出失败测试修改后再次推送即可让 CI 用更新后的代码重新运行。【免费下载链接】vSimple, fast, safe, compiled language for developing maintainable software. Compiles itself in 1s with zero library dependencies. Supports automatic C V translation. https://vlang.io项目地址: https://gitcode.com/GitHub_Trending/v/v创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考