根本原因是测试框架启动开销、重复加载环境或调试器附加阻塞;禁用自动调试附加最有效,精简测试文件匹配、优化并发与缓存、避免i/o操作及非必要插件可显著提速。

为什么 test runner 在 VSCode 里跑得慢
根本原因通常不是 VSCode 本身,而是测试框架启动开销、重复加载环境、或调试器附加导致的阻塞。比如 jest 默认每次运行都重建整个模块图,vitest 开启 watch 模式时若未配置 poolOptions,也会反复 fork 进程;而用 Debug: Start Debugging 运行测试时,VSCode 会强制启用调试协议,哪怕你没打断点,也会显著拖慢执行速度。
禁用自动调试附加(最立竿见影)
VSCode 的“运行测试”按钮默认走的是 debug 协议,即使你没配 launch.json 或没开断点,它仍会注入调试器代理——这对 Jest/Vitest/Mocha 都是纯负担。
- 打开命令面板(
Ctrl+Shift+P/Cmd+Shift+P),输入并选择:Testing: Configure Test Explorer - 在弹出的 JSON 中,确保
"testExplorer.execArgv"为空数组,或显式设为[] - 如果你用的是
vscode-jest插件,检查设置里是否勾选了jest.autoEnable和jest.debugMode——后者必须关掉 - 更彻底的方式:直接用终端运行测试(如
npm test -- --runInBand -t "login"),绕过插件层
限制测试并发与缓存复用
多核机器上盲目开启高并发反而因进程调度和内存争抢变慢;而每次重跑都清缓存,等于白做预编译。
-
jest:加--runInBand(单线程) +--cache(默认开启,但确认node_modules/.cache/jest可写) -
vitest:在vitest.config.ts中设poolOptions.threads.singleThread = true,并启用cache: { dir: './node_modules/.vitest' } -
ts-jest用户务必关掉isolatedModules: true(它会禁用 TypeScript 缓存),改用useESM: true+tsconfig正确继承 - 避免在
beforeAll里做 I/O(如读文件、连数据库),这类操作无法被缓存,且会阻塞整个测试套件
用 .vscode/settings.json 精简测试上下文
VSCode 测试服务会扫描整个工作区找测试文件,如果 node_modules、dist、coverage 被纳入,就会白白消耗 glob 匹配时间。
- 在项目根目录的
.vscode/settings.json中加入:
{
"testExplorer.files": "{src,test}/**/*.{test,spec}.{js,ts,jsx,tsx}",
"search.exclude": {
"**/node_modules": true,
"**/dist": true,
"**/coverage": true,
"**/.vitest": true,
"**/.jest": true
}
}
- 如果用
jest,再加一行"jest.pathToJest": "npm run test --"(注意双横杠),避免插件自己解析package.json脚本时出错 - 禁用非必要插件:比如
Wallaby.js和vscode-jest同时启用会导致冲突,只留一个
真正卡顿往往发生在「你以为只是点一下」的瞬间——比如 VSCode 尝试从 tsconfig.json 推导测试入口,却因为 extends 链太深或含远程 URL 而卡住几秒。这种细节不会报错,但会让测试响应像隔了一拍。











