vscode-test 是唯一能真正跑通 VS Code 插件测试的启动方式，因其可拉起带完整 API 注入的 Extension Host 进程，而 type: "node" 等方式导致 vscode 对象为空、命令注册失效；testRunner.js 必须导出 module.exports = { run }，且需提前编译 TypeScript 并严格匹配 glob 路径。
vscode-test 是唯一能真正跑通 VS Code 插件测试的启动方式，其他任何直接 node test/index.js 或用 type: "node" 的 launch 配置，都会让 vscode 全局对象为空，vscode.commands.registerCommand 等 API 根本不执行——你写的测试用例可能连入口都没进。
为什么 vscode-test 不可替代
VS Code 插件运行在 Extension Host 进程里，不是普通 Node.js 环境。只有 vscode-test 能拉起一个干净、隔离、带完整 API 注入的 VS Code 实例，并把你的扩展和测试代码一起加载进去。
常见错误现象：
-
Cannot read property 'commands' of undefined—— 说明你用了type: "node"，vscode对象根本没注入 - 断点不命中、
activate()没被调用、命令注册失效 —— 全是 Extension Host 流程没走通的表现 - 测试通过但 UI 完全没响应 —— 因为 Renderer 进程没参与，而你测的是 Webview 或状态栏交互
必须满足三个硬性条件：
-
launch.json中"type": "extensionHost" -
"runtimeExecutable": "${execPath}"（指向当前 VS Code 可执行文件，不是系统 Node） -
--extensionTestsPath指向一个 JS 文件（如out/test/testRunner.js），且该文件必须导出run函数
testRunner.js 是契约，不是可选胶水
它不是辅助脚本，而是 vscode-test 的强制入口协议：VS Code 测试 runner 只认这个文件，且只认 module.exports = { run } 形式。
哪怕你用 TypeScript 写测试，也得先编译成 JS，再由 testRunner.js 加载。示例最小结构：
const path = require('path');
const Mocha = require('mocha');
const glob = require('glob');
<p>async function run() {
const mocha = new Mocha({ ui: 'tdd' });
const testsPath = path.resolve(__dirname, '..', '..', 'test', '*<em>', '</em>.test.js');
glob.sync(testsPath).forEach(file => mocha.addFile(file));</p><p>return new Promise((resolve, reject) => {
mocha.run(failures => (failures ? reject(new Error(<code>${failures} failures</code>)) : resolve()));
});
}</p><p>module.exports = { run };注意点：
-
out/test/必须是编译输出目录，tsc -p ./test/tsconfig.json要提前执行 -
glob.sync路径要和实际 JS 输出位置严格匹配，别漏掉../..层级跳转 - 不能用 ES Module 语法（
export async function run()），vscode-test当前只支持 CommonJS
Python 测试配置别只靠 GUI 向导
VS Code 的 Python: Configure Tests 命令虽然方便，但生成的 .vscode/settings.json 很容易漏掉关键细节，导致测试发现失败或路径错乱。
典型问题场景：
- 项目根目录下有
tests/和src/tests/两个目录，向导默认只扫顶层，src/tests/里的用例不会被识别 -
python.testing.pytestArgs里没加--rootdir=.，pytest 会从当前打开文件夹向上找pyproject.toml，可能误读父级配置 - 使用
conftest.py自定义 fixture，但 VS Code 没启用python.testing.pytestEnabled，导致 fixture 不生效
推荐手动补全配置：
{
"python.testing.pytestEnabled": true,
"python.testing.unittestEnabled": false,
"python.testing.pytestArgs": [
"--rootdir=.",
"tests",
"-v",
"-p", "no:warnings"
]
}如果项目结构复杂，直接在项目根目录放 pytest.ini 更可靠：
[tool:pytest] testpaths = tests src/tests python_files = test_*.py *_test.py python_classes = Test* python_functions = test_*
GPT 类插件生成测试时最常忽略的上下文边界
GitHub Copilot 或 “GPT for VS Code” 能快速产出 describe/test 块，但生成结果往往脱离真实工程约束。
容易踩的坑：
- 生成的测试用了
jest.mock()，但项目实际用的是vitest，API 不兼容 - 断言写成
expect(x).toBe(1)，而项目配置了 Chai + Sinon，应为expect(x).to.equal(1) - 函数签名含异步逻辑（如返回
Promise），但生成测试没加await或return，导致用例永远 pending - 测试中引用了未导入的工具函数（如
deepEqual），运行时报ReferenceError
实操建议：
- 在提示词里明确指定框架：// Generate unit tests with vitest and expect().resolves.toEqual()
- 粘贴函数完整签名和 JSDoc，比只给函数体更利于生成准确 mock 和断言
- 生成后务必检查
import是否完整，尤其注意vi.mock()位置是否在顶层作用域
真正卡住人的从来不是“怎么配”，而是“配完之后为什么没反应”。比如 vscode-test 报 Extension activation failed 却不报具体错因，大概率是 package.json 里 activationEvents 没覆盖你测试触发的命令；又比如 pytest 显示 “0 tests collected”，八成是 testpaths 和文件命名规则对不上。这些细节不查日志、不看输出路径，光靠向导点几下根本绕不过去。
