vscode插件单元测试必须在真实或模拟的vscode环境中执行，因依赖extension api；官方推荐使用@vscode/test-electron启动electron版vscode实例运行集成测试，不可直接用jest在node环境运行。
VSCode插件本身的单元测试，不能靠 Jest 或 pytest 直接跑通——它依赖 VSCode 的 Extension API 运行时环境，必须在真实或模拟的 VSCode 主机进程中执行。
vscode-test 本地运行测试必须用 @vscode/test-electron
官方推荐且目前唯一稳定支持端到端插件行为验证的工具是 @vscode/test-electron（原 vscode-test）。它会下载指定版本的 VSCode（Electron 构建版），启动一个干净的“扩展开发主机”实例，在其中激活你的插件并运行测试代码。
- 不兼容 Node.js 原生环境：直接
npm test调 Jest 会报错Cannot find module 'vscode'，因为vscode是假模块，只在 VSCode 进程内注入 - 必须显式指定 VSCode 版本：例如
1.85.0，避免因 VSCode 内部 API 微调导致测试失败（比如workspace.fs在 1.84+ 才稳定） - 测试文件需导出
runTests函数，并通过testRunner启动：不能写成普通 Mocha/Jest 测试用例格式 - 示例最小测试入口：
import { runTests } from '@vscode/test-electron'; async function go() { try { await runTests({ extensionDevelopmentPath: path.resolve(__dirname, '..'), extensionTestsPath: path.resolve(__dirname, './suite/index'), version: '1.85.0', }); } catch (err) { console.error('Failed to run tests', err); process.exit(1); } } go();
测试中访问 vscode API 的正确姿势
插件测试不是在 Node.js 环境里调用 vscode，而是在被加载的 Extension Host 进程中，通过 vscode.workspace、vscode.window 等对象与编辑器交互。这些对象只有在 activate 被调用后才可用，且多数异步操作需显式等待。
- 不要在
beforeEach里直接访问vscode.workspace.rootPath：它可能为undefined，应改用vscode.workspace.getWorkspaceFolder(...)+await - 命令注册和触发必须配对：先
vscode.commands.registerCommand（通常在activate中），再用vscode.commands.executeCommand('my.extension.doSomething')触发，否则返回undefined - UI 操作（如弹窗、输入框）无法真正渲染，但可 mock：例如用
sinon.stub(vscode.window, 'showInputBox').resolves('test-input') - 文件系统操作要小心路径：测试工作区默认是临时目录，
vscode.workspace.fs.readFile读的是该临时路径下的文件，不是你源码目录
如何隔离测试状态避免污染
VSCode 插件测试默认复用同一个 Extension Host 实例，若多个测试用例修改了全局状态（如设置、已打开编辑器、注册的 disposables），极易相互干扰。
- 每个测试文件（
.ts）应在after钩子中清理所有Disposable：包括vscode.commands.registerCommand返回的对象、vscode.workspace.onDidChangeConfiguration订阅等 - 禁用用户设置干扰：启动测试时传入
--disable-extensions --user-data-dir=/tmp/vscode-test-xxx，避免本地插件或配置影响行为 - 不要依赖
vscode.window.activeTextEditor的初始值：它可能为null，应先用vscode.window.showTextDocument打开一个新文档再断言 - mock 全局状态比重置更可靠：例如用
jest.mock('vscode', () => ({...}))替换整个模块，仅在单元测试（非端到端）中使用；端到端仍需真实环境
最易被忽略的一点：插件测试的“慢”不是性能问题，而是环境初始化成本——每次 runTests 都要下载/解压 VSCode 二进制、启动 Electron、加载扩展。别试图在 CI 中反复跑全量测试；应把逻辑拆到纯 TypeScript 单元测试（用 Jest + mocked vscode），只用 @vscode/test-electron 验证关键集成路径，比如命令触发、文档变更响应、Webview 渲染回调。
