VSCode单元测试断点不中断的根本原因是调试器未与测试进程及源码映射对齐：Jest需--runInBand禁用并行，program须指向jest CLI而非源码，TS项目必须开启sourceMap和inlineSources，Python pytest需用module方式启动而非program直接运行test文件。
VSCode里跑单元测试时断点不中断、失败堆栈看不清、根本找不到错在哪行——不是测试没跑，是调试上下文压根没进对地方。必须让测试框架和VSCode调试器在同一个进程、同一套源码映射、同一次调用链里协同工作。
断点打了但测试运行直接跳过
这说明调试器没 attach 到实际执行测试的进程，或者 source map 没对上。Node.js（如 Jest）和 Python（如 pytest）表现不同，但根因一致：launch.json 或测试配置没桥接好调试通道。
- Jest 项目必须用
jest --runInBand启动，禁用并行；否则断点只在主进程生效，worker 进程完全不可控 - launch.json 中
program不能指向.ts源码，而要设为 Jest CLI 入口，例如"program": "${workspaceFolder}/node_modules/.bin/jest" - TypeScript 项目需确保
tsconfig.json含"sourceMap": true，且outDir与rootDir明确，否则断点会错位到编译后文件的任意行 - Python + pytest 场景下，
type必须是python，request为launch，module设为pytest，不能用program直接指 test_*.py 文件（那样会绕过 pytest 的收集机制）
测试失败但 CALL STACK 里只有 runner 代码
你看到的是 pytest.main() 或 jest-cli.js 的调用帧，而不是你的 test 函数内部——说明错误发生在异步边界外、或被 try/catch 吞了，也可能是测试框架做了异常拦截。
- Jest 默认捕获未处理 Promise rejection 并转为 test failed，但不会中断在 reject 行；需在 launch.json 加
"env": { "NODE_OPTIONS": "--unhandled-rejections=strict" }强制崩溃 - Pytest 若用
-x或--tb=short，会截断 traceback；调试时务必加--tb=long，并在 Debug Console 输入import traceback; traceback.print_exc()手动补全 - React/Vue 组件测试（如 @testing-library/react）中，异步行为（fireEvent.click + waitFor）若没 await，错误会抛在 test 函数外层；断点必须打在
await waitFor(...)内部回调里，而非 click 调用后
Debug Console 里访问不到测试变量
因为测试函数执行完就退出了作用域，暂停点不在 test 函数体内，而是在 runner 的 event loop tick 里——你看到的不是“那个 test”，而是“刚跑完 test 的壳”。
- 断点必须打在
it/test回调函数体第一行，或 assert 前一行；打在describe块里或beforeEach中无效 - 想查 fixture 数据？在 Jest 中用
console.log输出不如在 Debug Console 直接输expect.getState().currentSpec（Jest 内部状态），但更稳的是右键变量 →Store as global variable，生成temp1后再操作 - Pytest 中局部变量名会被优化掉（尤其
-O模式）；确保运行命令不含-O，且 launch.json 的console设为integratedTerminal，避免重定向丢失上下文
如何快速定位 assertion 失败的真实位置
多数 assertion 库（expect, assert, pytest.raises）失败时只抛 Error 对象，但原始比较值藏在 stack 或属性里，靠悬停根本看不到全貌。
- Jest 的
expect(x).toBe(y)失败后，在 Debug Console 输入error?.message可读到完整 diff，比面板里折叠的报错清晰得多 - Pytest 断言失败抛出
AssertionError，但error.args是 tuple，常含空字符串；真正内容在error.__traceback__.tb_next.tb_frame.f_locals里，可输list(error.__traceback__.tb_next.tb_frame.f_locals.items())查 - 别依赖 “跳转到失败行” 功能——它常定位到
assert False这种 wrapper 行；应手动在 assertion 行设断点，暂停后立刻查左值、右值、转换逻辑（如JSON.parse(str)是否出错）
最易忽略的是：单元测试调试必须和 CI 运行环境一致。本地用 npm test 能断住，CI 用 npx jest 就失效——因为路径解析、NODE_ENV、甚至 shell 类型（bash vs zsh）都可能影响模块加载顺序和 source map 解析。先同步命令，再调断点。
