VSCode调试Jest需同时满足launch.json配置--runInBand、tsconfig.json启用sourceMap和inlineSources、Orta插件正确设置rootPath和pathToJest,缺一断点即静默失效。

VSCode 调试 Jest 测试不是“装个插件就完事”,核心卡点在 launch.json 配置、source map 映射和 Jest 启动模式三者是否对齐——多数断点不命中、跳转错行、调试器卡在空行的问题,都源于其中一环没对上。
launch.json 必须用 --runInBand 启动 Jest
默认 Jest 会开多个子进程并行跑测试,而 VSCode 的 Node.js 调试器只能 attach 到主进程。不加 --runInBand,断点根本不会被触发,或者只在某个随机子进程里停住(你完全感知不到)。
-
program字段推荐写成"${workspaceFolder}/node_modules/.bin/jest"(macOS/Linux)或"${workspaceFolder}/node_modules/jest/bin/jest.js"(Windows),避免依赖全局jest命令 -
args至少包含"--runInBand";如需调试当前文件,补上"--runTestsByPath", "${file}" - 别用
runtimeArgs+--inspect-brk组合——它会让调试器卡在 Jest 入口,徒增手动 F5 次数 - 加
"autoAttachChildProcesses": true是冗余的,--runInBand下无子进程可 attach
TS 项目断点失效?检查 sourceMap 和 inlineSources
断点显示在编译后 JS 文件、空白行或 __tests__ 外部,基本是 source map 路径没解析对。VSCode 不读 tsconfig.json 里的 outDir,只认 sourceMap: true + inlineSources: true 这一对组合。
-
tsconfig.json中必须有:"sourceMap": true和"inlineSources": true(后者关键,否则 map 文件路径容易脱靶) - 如果用了
ts-jest,确认其版本与 TS 版本兼容;v29+ 对inlineSources更敏感 - 删掉
.vscode/launch.json里所有自定义outFiles或sourceMaps字段——VSCode 现在能自动处理 inline source map - 重启 VSCode,不是重载窗口,是彻底退出再打开,否则旧缓存可能干扰 source map 加载
Orta.vscode-jest 插件要配 jest.rootPath 和 jest.pathToJest
插件图标不亮、右键没 “Debug Test”、状态栏无 Jest 图标,大概率是插件找不到 Jest 配置入口。它不靠 package.json 里的 test script,而是直接读 jest.config.js 或 jest.config.ts,且对路径非常挑剔。
- 在
.vscode/settings.json中显式设"jest.rootPath": "./"(不能留空,也不能写".") - 若项目用 pnpm,配
"jest.pathToJest": "pnpm jest";用 npm/yarn 就写"npx jest"(注意引号) - 禁用其他 Jest 相关插件,比如 “Jest Test Explorer” 或 “Jest Runner”——它们和 Orta 插件抢
debugger协议,导致断点注册失败 - 配完必须重启 VSCode,不是重载,是 kill 进程再启
最易忽略的是:Jest 调试不是“启动即通”,而是 launch.json、tsconfig.json、插件配置三者必须同时满足条件。少一个,断点就静默失效——它不会报错,只会假装没看见你点的红点。











