直接写 jest 测试卡在样板代码是因为重复编写 describe/it/expect 结构和 import，vscode 插件如 jest snippets 可补全测试骨架、推导断言类型（需 @types/jest 和 ts 配置），quokka.js 实时验证断言，test explorer ui 统一运行，三者按“写→验→跑”顺序协同提效。
为什么直接写 jest 测试用例总卡在样板代码上？
因为每个测试文件都要手动写 describe、it、expect 结构，还要反复 import 同一个模块，稍不注意就漏掉 test 或拼错 toBe。这不是逻辑问题，是重复劳动消耗注意力。
VSCode 插件能帮你把「写测试」这件事降维成「填空」——不是生成完整测试，而是补全骨架、推导预期值、快速插入断言模板。
-
Jest Snippets（by orta）：输入test按 Tab 就展开带describe+it的结构，支持test.only、test.skip快捷补全 - 别装
JavaScript (ES6) code snippets这类泛用插件，它对jest的beforeEach/mockImplementation支持弱，容易补全错函数名 - 如果项目用
Vitest，换装Vitest Snippets，它的test.concurrent和expect.extend补全更准
如何让插件自动推导 expect 断言类型？
光有模板不够，真正卡住的是「该写 toBe 还是 toEqual？要不要加 .resolves？」——这得看被测函数返回值类型。插件本身不分析运行时类型，但可以借力 TS Server + jest 类型定义。
确保你的项目里已安装 @types/jest，且 jsconfig.json 或 tsconfig.json 中启用了 types: ["jest"]。这时 Jest Snippets 的 expect 补全会结合当前上下文提示更精准：
- 光标停在
expect(后按 Ctrl+Space，列出的选项会过滤掉不匹配返回类型的断言（比如 Promise 返回值时，toBe灰掉，resolves.toBe优先显示） - 如果插件没响应，先检查 VSCode 底部状态栏是否显示「TypeScript 正在加载」，没加载完时补全不可靠
- 避免在
.js文件里写expect(foo()).resolves.toBe(1)却没配@ts-check，否则类型推导失效，补全退化为纯字符串匹配
Quokka.js 不是替代 Jest，而是缩短「改一行代码 → 看结果」的路径
写测试用例时最耗神的环节，其实是验证「我写的这个断言逻辑对不对」。这时候跑完整 npm test 太重，而 Quokka.js 能在编辑器里实时执行光标所在行或选中块，直接输出 expect 的比对结果。
- 选中
expect(add(2, 3)).toBe(5)，右键选「Start Quokka on Selection」，立刻看到 ✅ 或 ❌ 及实际/期望值 - 它默认不走
jest.config.js，所以 mock 不生效——需要手动在 Quokka 配置里加"env": {"NODE_OPTIONS": "--experimental-vm-modules"}才能识别jest.mock - 别在 Quokka 里测异步副作用（比如调 API），它不等待事件循环清空，
setTimeout或fetch会直接返回undefined
插件组合用错顺序，反而拖慢节奏
三个高频插件：Jest Snippets（写）、Quokka.js（验）、Test Explorer UI（跑）。它们之间有隐含依赖关系，顺序乱了就白装。
- 必须先装
Test Explorer UI并配置好jest.path（指向本地node_modules/.bin/jest），否则Quokka的 mock 和Jest Snippets的test.todo补全无法联动工程级配置 -
Test Explorer UI的「Run Test At Cursor」功能，依赖当前文件已被jest识别为测试文件（即文件名含.test.或.spec.），否则右键菜单不出现「Run Test」项 - 如果同时开了 ESLint 报错提示，注意关闭
eslint-plugin-jest的no-test-callback规则——它会把it('desc', () => {})误判为错误，干扰补全
真正省时间的不是插件数量，是让它们在「写 → 验 → 跑」这条链路上不互相打断。比如补全一个 it 块后，光标自动落在 expect 里，而不是卡在括号外；Quokka 输出结果后，能一键跳转到对应 test 行——这些细节没对齐，再多插件也白搭。
