Python Test Explorer更值得用，因其支持点击跳转至失败测试的断点位置，结构化pytest输出并与VSCode调试器深度集成，可自动在assert行暂停而非卡在pytest.main()内部。
为什么 Python Test Explorer 比直接跑 pytest 命令更值得用
因为你能点一下就跳转到失败测试的断点位置，而不是在终端里翻几十行 traceback。它把 pytest 的输出结构化了，再和 VSCode 调试器深度绑定——比如点击某个测试项，自动启动调试会话并停在 assert 行，而不是卡在 pytest.main() 内部。
实操建议：
- 必须安装
Python Test Explorer（Microsoft 官方维护）和Python插件（后者提供调试支持） - 确保项目根目录下有
pytest.ini或pyproject.toml，否则插件可能识别不出测试文件（默认只扫描test_*.py和*_test.py） - 不要手动改
settings.json里的python.testing.pytestArgs，先让插件自动生成配置——它会在首次发现测试后，在工作区.vscode/settings.json里写入正确路径
调试单个测试函数时，launch.json 配置容易漏掉的关键字段
VSCode 默认不为测试生成 launch.json，但如果你手动创建或复用其他 Python 配置，常会忽略 purpose 和 console 这两个字段，导致断点不触发或输出乱码。
实操建议：
- 用插件右键测试 → “Debug Test”，它会自动创建临时调试配置；若需持久化，复制该配置到
.vscode/launch.json - 确认配置中包含：
"purpose": ["debug-test"]（这是 VSCode 识别“这是测试调试”的关键标记） -
"console": "integratedTerminal"必须显式设置，否则print()输出不会出现在调试控制台，而是在空窗口里一闪而过 - 避免写
"module": "pytest"—— 插件底层已处理模块调用，硬写反而干扰参数解析
运行 unittest 时，插件报 No module named 'tests' 的真实原因
不是路径没加进 PYTHONPATH，而是插件默认以当前工作区根为 sys.path[0]，而你的 tests/ 目录如果不在根下（比如在 src/tests/），unittest 就找不到包结构。
实操建议：
- 在
pyproject.toml中显式声明源码根：[tool.python-testing.source-directories] = ["src"]（Python Test Explorer支持此配置） - 或者改用相对导入：把测试文件放在与被测模块同级，用
from .mymodule import func，并确保__init__.py存在 - 别依赖
python.testing.cwd设置工作目录——它只影响命令执行路径，不改变sys.path加载逻辑
测试覆盖率高但调试时变量值显示 undefined 怎么办
常见于使用 pytest-asyncio 或 pytest-mock 的场景，本质是调试器无法在协程栈帧或 mock 对象内部提取变量，不是代码问题，是调试协议限制。
实操建议：
- 在可疑行前加
breakpoint()（Python 3.7+），比 IDE 断点更可靠，能强制进入真实执行上下文 - 对 async 测试，确保
launch.json中有"justMyCode": false，否则调试器会跳过 asyncio 内部帧，看不到事件循环状态 - mock 对象的返回值要显式赋给变量再断点查看，比如
result = mock_func()，而不是直接mock_func().attr—— 后者在调试器里常显示为undefined
真正麻烦的是跨进程测试（比如用 pytest-xdist）——插件根本不支持调试，得关掉 --numprocesses 参数再试。这点很容易被忽略，直到你花二十分钟调一个根本进不去的断点。
