Void 测试体系深度指南Unit / Integration / Smoke 三层测试的运行、调试与实战【免费下载链接】void开源AI代码编辑器Cursor的替代方案。项目地址: https://gitcode.com/GitHub_Trending/void2/voidVoid 作为一款开源 AI 代码编辑器Cursor 的替代方案其代码库沿用了 VS Code 成熟的分层测试架构。仓库根目录下的 test/README.md 是整个测试体系的索引入口它把全部测试工作划分为unit单元测试、integration集成测试、smoke自动化 UI 测试三大类并各自配套了独立的运行器与文档。本文将围绕这份索引文档展开完整继承其骨架并结合 test/unit/README.md、test/integration/browser/README.md、test/smoke/README.md 三份子文档以及仓库源码scripts/test.sh、package.json、test/smoke/src 等进行纵深扩充。读完后你将能够独立启动任一层次的测试、按需过滤用例、生成覆盖率报告并掌握冒烟测试中规避状态污染与竞态问题的工程经验。一、测试体系总览test 目录里到底有什么根据 test/README.md 的说明test目录是整个仓库测试运行器的集合每个子目录内都附有对应的运行文档子目录测试类型运行文档test/unit单元测试套件unit/README.mdtest/integrationAPI 集成测试套件integration/browser/README.mdtest/smoke自动化 UI 测试套件smoke/README.md除此之外从实际目录结构看test下还包含三个不写进顶层 README 的辅助设施值得一并了解test/automation一个独立的UI 自动化驱动包详见 automation/README.md它通过“从独立进程连接驱动”的方式自动化操作 VS Code UI是smoke测试的底层依赖test/monaco针对Monaco Editor 发行版的冒烟测试详见 monaco/README.md与主产品 UI 测试相互独立test/leaks内存泄漏检测相关脚本内部包含独立的 package.json 与 HTML 入口。一个值得注意的仓库事实是根 package.json 中的npm test并不会直接运行测试而是提示开发者去scripts目录选择对应的脚本test: echo Please run any of the test scripts from the scripts folder.因此实际运行测试的正确姿势是使用仓库根下的scripts/test.[sh|bat]、scripts/test-integration.[sh|bat]等脚本或是 package.json 中定义的test-browser、test-node、smoketest等 npm 脚本。二、单元测试Unit Tests三层运行环境覆盖最全单元测试是整个体系的第一道防线。根据 unit/README.md它可以在Electron 渲染进程、浏览器、纯 Node三种环境中运行各自覆盖不同的代码层。2.1 在 Electron 中运行默认推荐./scripts/test.sh # Linux / macOS scripts\test.bat # Windows所有单元测试默认运行在 Electron 渲染进程环境中该环境同时拥有DOM 与 Node.js API是最接近 Void 实际发布运行时的环境能捕获到浏览器/Node 环境下难以暴露的问题。从 scripts/test.sh 的实现可以看到脚本的关键行为自动推导仓库根目录ROOT并在 Linux 上追加--disable-dev-shm-usage参数——这是为了防止在 Docker 容器等/dev/shm分区小于 64MB 的环境中 Chromium 合成器因共享内存不足而 OOM通过npm run electron拉取 Electron 二进制以ELECTRON_ENABLE_LOGGING1方式启动test/unit/electron/index.js并指定--crash-reporter-directory.build/crashes收集崩溃转储方便定位渲染进程崩溃问题。常用选项--debug弹出带开发者工具的 Electron 窗口便于断点调试--run/--glob只运行指定子集。例如./scripts/test.sh --debug --glob **/extHost*.test.js会运行所有extHost文件对应的测试并进入调试模式npm run watch监听源码变更并自动增量编译配合测试可实现改码即测的迭代循环。2.2 在浏览器中运行Playwright 多内核覆盖npm run test-browser -- --browser webkit --browser chromium来自common与browser层的单元测试会通过 Playwright 在chromium、webkit以及文档标注“即将支持”的 firefox中执行与 Electron 运行器互补扩大跨平台覆盖率。两个值得注意的实战细节这些测试已纳入持续集成continuous build因此可能出现只在“Windows 上的 webkit”或“Linux 上的 chromium”才暴露的失败本地无法复现时优先怀疑平台差异本地调试可以直接在浏览器打开 test/unit/browser/renderer.html并通过?mamd_module查询参数指定要加载的 AMD 模块。例如renderer.html?mvs/base/test/common/strings.test会只运行strings.test.ts中的全部用例无需启动完整构建。浏览器运行同样支持--run/--glob过滤用例。若需查看 Playwright 库的底层 API 调用日志可在运行前设置环境变量DEBUG例如DEBUGpw:browser。2.3 用纯 Node 运行最快反馈回路npm run test-node -- --run src/vs/editor/test/browser/controller/cursor.test.tstest-node走的是根 package.json 定义的 Mocha 入口test/unit/node/index.js--delay --uitdd --timeout5000 --exit适合编辑器内核等纯逻辑代码的快速验证不必启动 Electron 或浏览器。它的目录结构对应关系为test/unit/electron、test/unit/browser、test/unit/node三个子入口分别承载上述三种运行方式。2.4 覆盖率报告以下命令会在仓库根目录.build下生成coverage文件夹macOS / Linux./scripts/test.sh --coverageWindowsscripts\test --coverage覆盖率数据由 test/unit/coverage.js 负责采集整理配合 test/unit/reporter.js 与 test/unit/fullJsonStreamReporter.js 输出结构化报告供 CI 或本地审计使用。三、集成测试Integration TestsAPI 与远程场景的真实验证集成测试位于test/integration其运行文档为 integration/browser/README.md用于在真实运行环境中验证 API 行为。3.1 先编译依赖首次运行前必须安装依赖并编译测试套件cd test/integration/browser npm i npm run compile编译产物由 test/integration/browser/src/index.ts 驱动的 Playwright 测试框架承载其package.json、tsconfig.json均在该目录内独立维护。3.2 在 Electron 中运行scripts/test-integration.sh # Linux / macOS scripts\test-integration.bat # Windows所有集成测试默认运行在一个 Electron 实例中。若要对真实发布构建进行验证可通过环境变量指定路径INTEGRATION_TEST_ELECTRON_PATH指向真实的 Electron/应用可执行文件VSCODE_REMOTE_SERVER_PATH如需包含远程Remote场景测试指向远程服务器构建。3.3 在浏览器中运行scripts/test-web-integration.[sh|bat] --browser [chromium|webkit] [--debug]集成测试也可运行在指定浏览器实例中追加--debug会弹出一个实时运行测试的浏览器窗口便于观察页面行为。同样的可通过设置DEBUG环境变量开启 Playwright 的详细 API 日志。3.4 在编辑器内调试所有集成测试Electron 与 Web 两种形态都可以直接在 VSCode 中运行与调试——只需选择仓库中预置的对应launch configuration即可无需手工拼参数。四、冒烟测试Smoke Tests端到端 UI 自动化的完整方案冒烟测试是最接近真实用户的一层通过自动化驱动真实编辑器 UI 完成工作流验证。其文档 smoke/README.md 也是三个子文档中内容最丰富的一份下面按“快速上手 → 发布验证 → 调试 → 开发 → 避坑”逐步展开。文档编写时要求运行在Node v12.x上。若当前仓库依赖版本更高请以本地node_modules中实际安装的运行时为准。4.1 快速上手# 1. 构建仓库内的扩展如需要 npm i npm run compile # 2. 开发模式Electron npm run smoketest # 3. 开发模式Web必须运行在发行版 distro 上 npm run smoketest -- --web --browser [chromium|webkit] # 4. 构建模式Electron指向最新版本的绝对路径 npm run smoketest -- --build /Applications/Visual\ Studio\ Code\ -\ Insiders.app # 5. 构建模式Web指向以 -web 结尾的服务器 Web 构建 npm run smoketest -- --build path to server web build (ends in -web) --web --browser [chromium|webkit] # 6. 远程模式Electron npm run smoketest -- --build path to latest version --remote其中“构建扩展”这一步仅在不带--build运行且.build/electron目录下不存在 OSS 构建时才必须执行。smoketest脚本的真实执行链在根 package.json 中定义smoketest: node build/lib/preLaunch.js cd test/smoke npm run compile node test/index.js, smoketest-no-compile: cd test/smoke node test/index.js即先执行 preLaunch 准备环境再编译test/smoke内的 TypeScript 源码最后启动 test/smoke/test/index.js 运行全部 UI 用例。4.2 为发布Endgame运行冒烟测试冒烟测试有严格的版本匹配要求必须运行与待测发布版本相同的冒烟测试版本。例如要测试release/1.22发布版就需要同步切换到该分支的冒烟测试代码git fetch git checkout release/1.22 npm i npm run compile cd test/smoke npm iWeb 发布版目前不支持“用旧版本测试新版本”反之亦然。正确做法是通过--build指向解压后的服务器 Web 构建文件夹的绝对路径例如 macOS 下的vscode-server-darwin-x64-web。服务器 Web 构建可从构建页面获取并注意macOS 上若下载的是带 Web 位的服务器压缩包解压前务必执行xattr -d com.apple.quarantine path to server with web folder zip否则 macOS 会在启动时触发安全限制务必指向包含客户端client bits的服务器否则测试无 UI 可驱动。4.3 调试参数--verbose打印所有对 Code 的底层 driver 调用日志用于定位“自动化操作与 UI 实际行为不一致”的问题-f PATTERN别名-g PATTERN按模式过滤要运行的测试兼容绝大多数 Mocha 参数--headless在使用--web时让 Playwright 以无头模式运行环境变量DEBUG如DEBUGpw:browser可开启 Playwright 库的详细 API 日志。4.4 开发冒烟测试cd test/smoke npm run watchtest/smoke/src是冒烟测试的全部源码所在其areas目录按功能区组织用例直接体现了这套测试覆盖的产品面extensions扩展安装与激活流程extensions.test.tslanguages语言模式行为languages.test.tsmultiroot多根工作区multiroot.test.tsnotebookNotebook 工作流notebook.test.tspreferences偏好设置preferences.test.tssearch搜索视图search.test.tsstatusbar状态栏statusbar.test.tstask任务与快速选择task.test.ts、task-quick-pick.test.tsterminal终端全场景输入、持久化、Profile、Shell 集成、Split CWD、Sticky Scroll、Tabs、编辑器模式等十余个文件见 test/smoke/src/areas/terminalworkbench数据丢失防护、启动、本地化data-loss.test.ts、launch.test.ts、localization.test.ts用例入口由 main.ts 统一编排通过test/automation提供的自动化 driver 与 UI 交互。4.5 故障排查错误Could not get a unique tmp filename, max tries reachedWindows 上请检查C:\Users\username\AppData\Local\Temp\t目录。如果该目录存在tmp模块将无法正常工作从而抛出上述错误删除该t目录即可解决。4.6 避坑清单PitfallsUI 测试的工程铁律smoke/README.md用一整节总结了编写 UI 测试时必须警惕的四类陷阱这些经验对所有 UI 自动化测试都适用状态State同一套件内的测试共享工作区状态前一个用例的残留文件、配置、编辑历史会传染后续用例编写时必须显式清理单例Singletons文件系统路径、TCP 端口、IPC 句柄等“单例资源”是并发的头号杀手。任何测试与测试架构必须保证可以与其他测试同时运行甚至能与自身并行——所有套件都应具备被反复并行执行的能力焦点Focus永远不要依赖 DOM 元素的焦点状态如.focused类或:focus伪类因为一旦有另一个窗口覆盖到运行中的编辑器窗口焦点就会丢失。安全做法是使用waitForActiveElementAPI大多数用例在等待某个元素获得焦点时都使用它时序Timing读写 DOM 之前要问自己——现在是正确时机吗你能 100% 保证那个input框此刻可见吗“希望它可见”是 UI 测试的大敌。例如按下F1触发快速访问后并不意味着输入框已经打开可以开始打字必须先等待输入元素进入 DOM 并成为当前活动元素等待Waiting任何等待都不应超过几秒钟除非理由充分。把测试想象成人类使用编辑器真人不会花 10 分钟跑完一个搜索视图测试机器应当更快。不要无脑setTimeout而是想清楚该等 DOM 中的什么就绪然后针对性地去等待它。五、辅助测试设施Automation 驱动与 Monaco 测试理解test全貌还需要两份配套文档UI 自动化驱动test/automation/README.md 说明该包通过一个“从独立进程连接的自动化 driver”来驱动 VS Code UI 的各个组件是smoke测试的底层依赖。这意味着冒烟测试与编辑器进程分离、通过 driver 协议通信从而可以稳定地跨进程操作界面。Monaco 编辑器测试test/monaco/README.md 用于对 Monaco Editor 发行版做冒烟验证流程为npm i npm run bundle打包发行版随后npm run compile npm run test编译并执行测试与主产品 UI 的冒烟测试相互独立。结语Void 的测试体系是一条完整的质量防线单元测试在 Electron/浏览器/Node 三层环境中验证代码逻辑集成测试在真实运行时中校验 API 与远程场景冒烟测试则通过自动化 driver 端到端地驱动真实 UI 覆盖搜索、终端、任务、工作区等核心功能。无论你是想为编辑器贡献代码、排查平台相关的偶发失败还是为发行版本做发布前把关都可以从 test/README.md 出发按本文梳理的命令逐层启动对应测试并借助--glob过滤、--debug调试与覆盖率报告快速定位问题。【免费下载链接】void开源AI代码编辑器Cursor的替代方案。项目地址: https://gitcode.com/GitHub_Trending/void2/void创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考