void 编辑器 Smoke Test 完整指南从本地开发到 Release 验收的端到端 UI 自动化测试【免费下载链接】void开源AI代码编辑器Cursor的替代方案。项目地址: https://gitcode.com/GitHub_Trending/void2/void导读本文以仓库中的 test/smoke/README.md 为骨架系统讲解 void 编辑器开源 AI 代码编辑器Cursor 的替代方案Smoke Test冒烟测试的完整运行体系涵盖 Dev/Build 两种构建来源与 Electron/Web/Remote 三类运行目标的全部组合、命令行参数全解析、Release 验收Endgame的版本匹配策略、调试手段以及编写稳定 UI 测试必须避开的五大陷阱。读完本文你将能够在本地或 CI 中一键跑通整条端到端 UI 测试链路并具备排查失败、扩写测试套件的实战能力。一、Smoke Test 在 void 项目中的定位与架构Smoke Test 是端到端E2EUI 测试它真实启动编辑器进程或浏览器 Web 版本通过一个独立的自动化驱动进程模拟用户在界面上的操作打开视图、输入搜索、切换设置、操作终端等并断言界面状态符合预期。它位于单元测试之上、人工验收之下用于在每次构建后快速确认主流程没有坏。在 void 仓库中这套体系由两层组成test/smoke测试用例层。src/areas/下按功能域组织测试套件搜索、终端、任务、状态栏、扩展、多根工作区、Notebook、语言、偏好设置、工作台等通过 package.json 中的compile脚本与test/automation一起编译后由 Mocha 驱动执行。test/automation自动化驱动层。按 test/automation/README.md 的描述它contains functionality for automating various components of the VS Code UI, via an automation driver that connects from a separate process即以独立进程通过 driver 连接编辑器 UI暴露Application、Workbench、Code等高级封装见 test/automation/src/application.ts。根目录 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其中smoketest会先执行preLaunch准备构建产物再编译自动化与 smoke 测试代码最后交给 test/smoke/test/index.js 启动 Mochagrep取-f/-g参数默认超时 2 分钟见该文件第 21-26 行。二、环境准备原文档要求确保Node v12.x。需要注意当前仓库测试基础设施的依赖声明已迭代test/smoke/package.json 中types/node为20.xTypeScript 编译目标为es2020见 test/smoke/tsconfig.json。因此实际运行时请以仓库当前package.json声明的 Node 版本约束为准并保证 npm 可用。首次运行前需要安装依赖并完成编译# 在仓库根目录执行安装依赖并编译自动化/测试代码 npm i npm run compile说明仅当以不带--build的方式运行、且.build/electron目录下还不存在 OSS 构建产物时npm i npm run compile才是必须的。三、快速开始五种运行模式原文档给出了完整的命令矩阵这里逐一展开1. DevElectron—— 针对源码运行npm run smoketest此模式从源码直接驱动开发版 Electron 进程。从 test/smoke/src/main.ts 的源码结构看未传--build时会调用getDevElectronPath()定位开发版可执行文件并设置VSCODE_REPOSITORY、VSCODE_DEV1、VSCODE_CLI1环境变量若找不到产物会提示先通过scripts/code.sh或scripts\code.bat运行一次编辑器。2. DevWeb—— 必须在发行版distro上运行npm run smoketest -- --web --browser [chromium|webkit]Web 模式需要指定 Playwright 浏览器内核。--web分支的逻辑见 test/smoke/src/main.ts未提供--build时同样设置VSCODE_DEV1直接对源码中的 Web 版执行测试。3. BuildElectron—— 针对正式构建产物npm run smoketest -- --build path to latest version # 示例macOS npm run smoketest -- --build /Applications/Visual\ Studio\ Code\ -\ Insiders.app--build指向最新构建的产物路径运行器通过getBuildElectronPath()/getBuildVersion()解析可执行文件与版本见 test/smoke/src/main.ts。4. BuildWeb—— 针对 Web 服务端构建npm run smoketest -- --build path to server web build (ends in -web) --web --browser [chromium|webkit]--build需指向解压后的服务端 Web 构建目录目录名以-web结尾具体获取方式见下文的 Release 小节。5. RemoteElectron—— 远程开发场景npm run smoketest -- --build path to latest version --remote在桌面端连接远程环境的场景下运行Application#checkWindowReady会额外等待状态栏远程指示器离开 Opening Remote 状态见 test/automation/src/application.ts。四、命令行参数全解析原文档提到的参数只是入口完整参数集可以从 test/smoke/src/main.ts 的minimist配置中确认参数类型说明--webboolean以浏览器 Web 模式运行--remoteboolean以远程Remote模式运行--build pathstring指定被测构建产物路径Electron 应用或-web服务端目录--stable-build pathstring指定上一个稳定版路径用于迁移/数据丢失类测试--browser [chromium\|webkit]stringWeb 模式下指定 Playwright 浏览器内核--verboseboolean开启详细日志默认 false同时向控制台输出日志--headlessbooleanWeb 模式下让 Playwright 以无头模式运行--tracingboolean开启 Playwright 跟踪录制每个用例前startTracing失败时持久化见 test/smoke/src/utils.ts-f PATTERN/-g PATTERNstring按 Mocha grep 模式过滤用例别名关系见 test/smoke/test/index.js--test-repo pathstring指定本地测试项目仓库路径以替代默认克隆见 test/smoke/src/main.ts--electronArgs argsstring向被测 Electron 进程追加启动参数按空格拆分见 test/smoke/src/main.ts--wait-timestring保留的超时配置项日志与崩溃产物位置运行器会根据模式把日志写入不同目录test/smoke/src/main.tsElectron.build/logs/smoke-tests-electron、.build/crashes/smoke-tests-electronWeb.build/logs/smoke-tests-browser、.build/crashes/smoke-tests-browserRemote.build/logs/smoke-tests-remote、.build/crashes/smoke-tests-remote运行器日志固定写入smoke-test-runner.log每个测试套件还会生成带序号与套件名的子目录N_suite_name见 test/smoke/src/utils.ts。测试失败后test/smoke/test/index.js 会提示日志存放位置方便回溯。测试工作区与 Quality 解析从源码可以确认两条运行时细节测试会在系统临时目录创建vscsmoke数据区克隆专用测试仓库默认vscode-smoketest-express必要时执行git fetch/reset --hard/clean重置见 test/smoke/src/main.ts。套件结束后临时目录会被清理。被测构建的质量档位由环境变量决定test/smoke/src/main.tsVSCODE_DEV1时为 Dev否则按VSCODE_QUALITY取stable/insider/exploration/oss缺省回退 Dev。部分套件如扩展、本地化只在非 Dev/OSS 档位下注册见 test/smoke/src/main.ts。五、ReleaseEndgame版本匹配运行验收发布版本时必须让 smoke test 与待测版本匹配如果要为release/1.22这类发布分支跑冒烟测试需要同步切到该分支的测试代码git fetch git checkout release/1.22 npm i npm run compile cd test/smoke npm itest/smoke作为独立 npm 包见 test/smoke/package.json需要单独安装依赖。Web 模式的版本说明当前 Web 模式**尚不支持用旧版测试新版**的跨版本方案。正确做法是从构建页面获取服务端 Web 构建包解压后用--build指向其绝对路径例如 macOS 下的vscode-server-darwin-x64-web。务必选择包含客户端资源的服务端包。macOS 上如果下载的压缩包带有隔离属性解压前需要先清除避免启动时出现安全拦截xattr -d com.apple.quarantine path to server with web folder zip此外当以--build运行且非 Web/Remote 时运行器会尝试通过更新服务器自动获取上一个稳定版用于数据丢失/迁移类用例也可用--stable-build显式指定见 test/smoke/src/main.ts。六、Debug如何诊断失败的测试原文档给出三个常用调试手段结合源码可进一步明确其行为--verbose把底层 driver 对编辑器的所有调用全部打印出来控制台 日志文件双写见 test/smoke/src/main.ts。-f PATTERN/-g PATTERN按 Mocha grep 过滤要执行的用例因为 grep 直接透传给 Mocha所以几乎任何 Mocha 参数都可以用。--headlessWeb 模式下让 Playwright 无头运行。如需开启 Playwright 库自身的详细 API 日志可在运行前设置DEBUG环境变量例如DEBUGpw:browser这是 Playwright 官方提供的 verbose API logs 开关可按需取值。CI 集成提示当设置了BUILD_ARTIFACTSTAGINGDIRECTORY环境变量时test/smoke/test/index.js 会自动切换为mocha-multi-reporters输出 JUnit XML 报告到指定目录便于 CI 汇总测试结果失败时日志以构建产物形式附加并提示可用 Playwright 轨迹查看器分析 trace。七、开发模式增量编译测试代码修改测试用例或自动化驱动后可在test/smoke目录下启动 watch 编译实现改完即跑cd test/smoke npm run watch该脚本并行监听test/automation与test/smoke两个包的编译见 test/smoke/package.json配合npm run smoketest-no-compile可跳过重复编译直接运行。八、测试套件结构与编写入口从 test/smoke/src/main.ts 可以看出主入口用describe按目标平台条件注册了全部套件数据丢失仅 Electron、偏好设置、搜索、Notebook仅 Electron、语言、终端、任务、状态栏、扩展仅非 Dev/OSS、多根工作区、本地化仅桌面、启动仅桌面。每个功能套件采用setup(logger)导出 installAllHandlers(logger)的固定模式后者统一安装套件级 before/after 与用例级 beforeEach/afterEach日志、trace 启停、应用启停见 test/smoke/src/utils.ts。以 test/smoke/src/areas/search/search.test.ts 为范例用例直接通过app.workbench.search等驱动封装操作 UI 并断言结果文本it(searches for body checks for correct result number, async function () { const app this.app as Application; await app.workbench.search.openSearchViewlet(); await app.workbench.search.searchFor(body); await app.workbench.search.waitForResultText(6 results in 3 files); });值得注意的是 test/smoke/src/areas/workbench/launch.test.ts它通过installAllHandlers(logger, opts ({ ...opts, userDataDir: join(opts.userDataDir, ø) }))二次加工应用选项验证用户数据目录含非 ASCII 字符时编辑器仍能正常启动。utils.ts还提供了几个高频工具describeRepeat/itRepeat重复注册同一套件/用例用于探测偶发失败test/smoke/src/utils.ts。retryWithRestart用例失败后自动重启编辑器应用再重试最多 N 次test/smoke/src/utils.ts。getRandomUserDataDir为每次启动生成随机 userData 目录后缀避免路径过长与状态串扰test/smoke/src/utils.ts。九、Troubleshooting常见错误处理错误信息Could not get a unique tmp filename, max tries reached这是 Windows 专属问题若存在C:\Users\username\AppData\Local\Temp\t目录tmp模块将无法正常工作并抛出上述错误。解决办法是删除该t目录后重试。另外如果以--build运行时无法定位产物test/smoke/src/main.ts 会直接报错并提示先用scripts/code.sh或scripts\code.bat运行一次编辑器生成开发产物。十、编写稳定 UI 测试的五大陷阱这是原文档的精华所在也是 UI 自动化最容易翻车的地方警惕 workbench 状态state同一套件内的用例共享同一份编辑器状态。用例之间必须考虑状态继承关系必要时在 after 中重置如 search 套件末尾执行git checkout .与git reset --hard HEAD还原工作区见 test/smoke/src/areas/search/search.test.ts。警惕单例singletons单例会以 FS 路径、TCP 端口、IPC 句柄等形式潜伏。写测试或搭建 smoke 架构时必须保证它可以与其他测试、甚至与自身同时并行运行——所有套件都应具备多次并行执行的能力。警惕焦点focus永远不要依赖.focusedclass 或:focus伪类判断焦点因为一旦另一个窗口盖住被测编辑器窗口焦点状态就会丢失。安全做法是使用waitForActiveElementAPI 等待某个元素成为活动元素多数用例都是这样等待焦点到位的。警惕时序timing读 DOM / 写 DOM 之前要问自己现在真的是正确的时机吗能 100% 保证输入框此刻可见吗还是只是在赌——在 UI 测试里侥幸心理是最危险的敌人。例如按F1触发 Quick Access 后并不意味着它已经打开、可以立刻输入必须先等输入元素进入 DOM 且成为当前活动元素。警惕等待waiting除非确有理由任何等待都不要超过几秒。想象一个真人用编辑器——真人不会花 10 分钟跑一遍搜索视图的冒烟用例那计算机应该更快。不要随手setTimeout而应想清楚DOM 中什么条件就绪了再去等那个条件。这五条原则在代码中均有呼应例如Application#checkWindowReady依次等待导航完成、.monaco-workbench元素出现、工作台恢复test/automation/src/application.ts正是等待明确条件而非固定时长的典型实现。此外test/smoke/Audit.md 记录了历史上因 DOM 属性如a[title]变更导致用例失效的真实案例并提示优先为被测元素绑定data-*属性来降低 UI 变更对测试的冲击——编写新用例时可以借鉴这一稳定性经验。【免费下载链接】void开源AI代码编辑器Cursor的替代方案。项目地址: https://gitcode.com/GitHub_Trending/void2/void创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 void 编辑器 Smoke Test 完整指南：从本地开发到 Release 验收的端到端 UI 自动化测试
void 编辑器 Smoke Test 完整指南从本地开发到 Release 验收的端到端 UI 自动化测试【免费下载链接】void开源AI代码编辑器Cursor的替代方案。项目地址: https://gitcode.com/GitHub_Trending/void2/void导读本文以仓库中的 test/smoke/README.md 为骨架系统讲解 void 编辑器开源 AI 代码编辑器Cursor 的替代方案Smoke Test冒烟测试的完整运行体系涵盖 Dev/Build 两种构建来源与 Electron/Web/Remote 三类运行目标的全部组合、命令行参数全解析、Release 验收Endgame的版本匹配策略、调试手段以及编写稳定 UI 测试必须避开的五大陷阱。读完本文你将能够在本地或 CI 中一键跑通整条端到端 UI 测试链路并具备排查失败、扩写测试套件的实战能力。一、Smoke Test 在 void 项目中的定位与架构Smoke Test 是端到端E2EUI 测试它真实启动编辑器进程或浏览器 Web 版本通过一个独立的自动化驱动进程模拟用户在界面上的操作打开视图、输入搜索、切换设置、操作终端等并断言界面状态符合预期。它位于单元测试之上、人工验收之下用于在每次构建后快速确认主流程没有坏。在 void 仓库中这套体系由两层组成test/smoke测试用例层。src/areas/下按功能域组织测试套件搜索、终端、任务、状态栏、扩展、多根工作区、Notebook、语言、偏好设置、工作台等通过 package.json 中的compile脚本与test/automation一起编译后由 Mocha 驱动执行。test/automation自动化驱动层。按 test/automation/README.md 的描述它contains functionality for automating various components of the VS Code UI, via an automation driver that connects from a separate process即以独立进程通过 driver 连接编辑器 UI暴露Application、Workbench、Code等高级封装见 test/automation/src/application.ts。根目录 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其中smoketest会先执行preLaunch准备构建产物再编译自动化与 smoke 测试代码最后交给 test/smoke/test/index.js 启动 Mochagrep取-f/-g参数默认超时 2 分钟见该文件第 21-26 行。二、环境准备原文档要求确保Node v12.x。需要注意当前仓库测试基础设施的依赖声明已迭代test/smoke/package.json 中types/node为20.xTypeScript 编译目标为es2020见 test/smoke/tsconfig.json。因此实际运行时请以仓库当前package.json声明的 Node 版本约束为准并保证 npm 可用。首次运行前需要安装依赖并完成编译# 在仓库根目录执行安装依赖并编译自动化/测试代码 npm i npm run compile说明仅当以不带--build的方式运行、且.build/electron目录下还不存在 OSS 构建产物时npm i npm run compile才是必须的。三、快速开始五种运行模式原文档给出了完整的命令矩阵这里逐一展开1. DevElectron—— 针对源码运行npm run smoketest此模式从源码直接驱动开发版 Electron 进程。从 test/smoke/src/main.ts 的源码结构看未传--build时会调用getDevElectronPath()定位开发版可执行文件并设置VSCODE_REPOSITORY、VSCODE_DEV1、VSCODE_CLI1环境变量若找不到产物会提示先通过scripts/code.sh或scripts\code.bat运行一次编辑器。2. DevWeb—— 必须在发行版distro上运行npm run smoketest -- --web --browser [chromium|webkit]Web 模式需要指定 Playwright 浏览器内核。--web分支的逻辑见 test/smoke/src/main.ts未提供--build时同样设置VSCODE_DEV1直接对源码中的 Web 版执行测试。3. BuildElectron—— 针对正式构建产物npm run smoketest -- --build path to latest version # 示例macOS npm run smoketest -- --build /Applications/Visual\ Studio\ Code\ -\ Insiders.app--build指向最新构建的产物路径运行器通过getBuildElectronPath()/getBuildVersion()解析可执行文件与版本见 test/smoke/src/main.ts。4. BuildWeb—— 针对 Web 服务端构建npm run smoketest -- --build path to server web build (ends in -web) --web --browser [chromium|webkit]--build需指向解压后的服务端 Web 构建目录目录名以-web结尾具体获取方式见下文的 Release 小节。5. RemoteElectron—— 远程开发场景npm run smoketest -- --build path to latest version --remote在桌面端连接远程环境的场景下运行Application#checkWindowReady会额外等待状态栏远程指示器离开 Opening Remote 状态见 test/automation/src/application.ts。四、命令行参数全解析原文档提到的参数只是入口完整参数集可以从 test/smoke/src/main.ts 的minimist配置中确认参数类型说明--webboolean以浏览器 Web 模式运行--remoteboolean以远程Remote模式运行--build pathstring指定被测构建产物路径Electron 应用或-web服务端目录--stable-build pathstring指定上一个稳定版路径用于迁移/数据丢失类测试--browser [chromium\|webkit]stringWeb 模式下指定 Playwright 浏览器内核--verboseboolean开启详细日志默认 false同时向控制台输出日志--headlessbooleanWeb 模式下让 Playwright 以无头模式运行--tracingboolean开启 Playwright 跟踪录制每个用例前startTracing失败时持久化见 test/smoke/src/utils.ts-f PATTERN/-g PATTERNstring按 Mocha grep 模式过滤用例别名关系见 test/smoke/test/index.js--test-repo pathstring指定本地测试项目仓库路径以替代默认克隆见 test/smoke/src/main.ts--electronArgs argsstring向被测 Electron 进程追加启动参数按空格拆分见 test/smoke/src/main.ts--wait-timestring保留的超时配置项日志与崩溃产物位置运行器会根据模式把日志写入不同目录test/smoke/src/main.tsElectron.build/logs/smoke-tests-electron、.build/crashes/smoke-tests-electronWeb.build/logs/smoke-tests-browser、.build/crashes/smoke-tests-browserRemote.build/logs/smoke-tests-remote、.build/crashes/smoke-tests-remote运行器日志固定写入smoke-test-runner.log每个测试套件还会生成带序号与套件名的子目录N_suite_name见 test/smoke/src/utils.ts。测试失败后test/smoke/test/index.js 会提示日志存放位置方便回溯。测试工作区与 Quality 解析从源码可以确认两条运行时细节测试会在系统临时目录创建vscsmoke数据区克隆专用测试仓库默认vscode-smoketest-express必要时执行git fetch/reset --hard/clean重置见 test/smoke/src/main.ts。套件结束后临时目录会被清理。被测构建的质量档位由环境变量决定test/smoke/src/main.tsVSCODE_DEV1时为 Dev否则按VSCODE_QUALITY取stable/insider/exploration/oss缺省回退 Dev。部分套件如扩展、本地化只在非 Dev/OSS 档位下注册见 test/smoke/src/main.ts。五、ReleaseEndgame版本匹配运行验收发布版本时必须让 smoke test 与待测版本匹配如果要为release/1.22这类发布分支跑冒烟测试需要同步切到该分支的测试代码git fetch git checkout release/1.22 npm i npm run compile cd test/smoke npm itest/smoke作为独立 npm 包见 test/smoke/package.json需要单独安装依赖。Web 模式的版本说明当前 Web 模式**尚不支持用旧版测试新版**的跨版本方案。正确做法是从构建页面获取服务端 Web 构建包解压后用--build指向其绝对路径例如 macOS 下的vscode-server-darwin-x64-web。务必选择包含客户端资源的服务端包。macOS 上如果下载的压缩包带有隔离属性解压前需要先清除避免启动时出现安全拦截xattr -d com.apple.quarantine path to server with web folder zip此外当以--build运行且非 Web/Remote 时运行器会尝试通过更新服务器自动获取上一个稳定版用于数据丢失/迁移类用例也可用--stable-build显式指定见 test/smoke/src/main.ts。六、Debug如何诊断失败的测试原文档给出三个常用调试手段结合源码可进一步明确其行为--verbose把底层 driver 对编辑器的所有调用全部打印出来控制台 日志文件双写见 test/smoke/src/main.ts。-f PATTERN/-g PATTERN按 Mocha grep 过滤要执行的用例因为 grep 直接透传给 Mocha所以几乎任何 Mocha 参数都可以用。--headlessWeb 模式下让 Playwright 无头运行。如需开启 Playwright 库自身的详细 API 日志可在运行前设置DEBUG环境变量例如DEBUGpw:browser这是 Playwright 官方提供的 verbose API logs 开关可按需取值。CI 集成提示当设置了BUILD_ARTIFACTSTAGINGDIRECTORY环境变量时test/smoke/test/index.js 会自动切换为mocha-multi-reporters输出 JUnit XML 报告到指定目录便于 CI 汇总测试结果失败时日志以构建产物形式附加并提示可用 Playwright 轨迹查看器分析 trace。七、开发模式增量编译测试代码修改测试用例或自动化驱动后可在test/smoke目录下启动 watch 编译实现改完即跑cd test/smoke npm run watch该脚本并行监听test/automation与test/smoke两个包的编译见 test/smoke/package.json配合npm run smoketest-no-compile可跳过重复编译直接运行。八、测试套件结构与编写入口从 test/smoke/src/main.ts 可以看出主入口用describe按目标平台条件注册了全部套件数据丢失仅 Electron、偏好设置、搜索、Notebook仅 Electron、语言、终端、任务、状态栏、扩展仅非 Dev/OSS、多根工作区、本地化仅桌面、启动仅桌面。每个功能套件采用setup(logger)导出 installAllHandlers(logger)的固定模式后者统一安装套件级 before/after 与用例级 beforeEach/afterEach日志、trace 启停、应用启停见 test/smoke/src/utils.ts。以 test/smoke/src/areas/search/search.test.ts 为范例用例直接通过app.workbench.search等驱动封装操作 UI 并断言结果文本it(searches for body checks for correct result number, async function () { const app this.app as Application; await app.workbench.search.openSearchViewlet(); await app.workbench.search.searchFor(body); await app.workbench.search.waitForResultText(6 results in 3 files); });值得注意的是 test/smoke/src/areas/workbench/launch.test.ts它通过installAllHandlers(logger, opts ({ ...opts, userDataDir: join(opts.userDataDir, ø) }))二次加工应用选项验证用户数据目录含非 ASCII 字符时编辑器仍能正常启动。utils.ts还提供了几个高频工具describeRepeat/itRepeat重复注册同一套件/用例用于探测偶发失败test/smoke/src/utils.ts。retryWithRestart用例失败后自动重启编辑器应用再重试最多 N 次test/smoke/src/utils.ts。getRandomUserDataDir为每次启动生成随机 userData 目录后缀避免路径过长与状态串扰test/smoke/src/utils.ts。九、Troubleshooting常见错误处理错误信息Could not get a unique tmp filename, max tries reached这是 Windows 专属问题若存在C:\Users\username\AppData\Local\Temp\t目录tmp模块将无法正常工作并抛出上述错误。解决办法是删除该t目录后重试。另外如果以--build运行时无法定位产物test/smoke/src/main.ts 会直接报错并提示先用scripts/code.sh或scripts\code.bat运行一次编辑器生成开发产物。十、编写稳定 UI 测试的五大陷阱这是原文档的精华所在也是 UI 自动化最容易翻车的地方警惕 workbench 状态state同一套件内的用例共享同一份编辑器状态。用例之间必须考虑状态继承关系必要时在 after 中重置如 search 套件末尾执行git checkout .与git reset --hard HEAD还原工作区见 test/smoke/src/areas/search/search.test.ts。警惕单例singletons单例会以 FS 路径、TCP 端口、IPC 句柄等形式潜伏。写测试或搭建 smoke 架构时必须保证它可以与其他测试、甚至与自身同时并行运行——所有套件都应具备多次并行执行的能力。警惕焦点focus永远不要依赖.focusedclass 或:focus伪类判断焦点因为一旦另一个窗口盖住被测编辑器窗口焦点状态就会丢失。安全做法是使用waitForActiveElementAPI 等待某个元素成为活动元素多数用例都是这样等待焦点到位的。警惕时序timing读 DOM / 写 DOM 之前要问自己现在真的是正确的时机吗能 100% 保证输入框此刻可见吗还是只是在赌——在 UI 测试里侥幸心理是最危险的敌人。例如按F1触发 Quick Access 后并不意味着它已经打开、可以立刻输入必须先等输入元素进入 DOM 且成为当前活动元素。警惕等待waiting除非确有理由任何等待都不要超过几秒。想象一个真人用编辑器——真人不会花 10 分钟跑一遍搜索视图的冒烟用例那计算机应该更快。不要随手setTimeout而应想清楚DOM 中什么条件就绪了再去等那个条件。这五条原则在代码中均有呼应例如Application#checkWindowReady依次等待导航完成、.monaco-workbench元素出现、工作台恢复test/automation/src/application.ts正是等待明确条件而非固定时长的典型实现。此外test/smoke/Audit.md 记录了历史上因 DOM 属性如a[title]变更导致用例失效的真实案例并提示优先为被测元素绑定data-*属性来降低 UI 变更对测试的冲击——编写新用例时可以借鉴这一稳定性经验。【免费下载链接】void开源AI代码编辑器Cursor的替代方案。项目地址: https://gitcode.com/GitHub_Trending/void2/void创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考