python test explorer 更省时因上下文感知：光标停函数上右键即生成测试桩，自动填参、mock，免切窗/手写前缀；但需正确配置pytest路径及环境，否则无生成选项。
为什么 Python Test Explorer 比手动写 pytest 文件更省时间
因为它是真正在编辑器里“感知上下文”的：光标停在某个函数上，右键就能生成对应测试桩，不用切窗口、不手写 test_ 前缀、不查参数类型。它会自动读取函数签名，填好 mock 占位或空参调用，尤其适合 TDD 初期快速铺开骨架。
但前提是必须先配置好测试框架识别路径——否则右键菜单压根不出现 Generate test 选项。常见卡点是：pytest 没装在当前 Python 环境里，或者 settings.json 里 python.testing.pytestArgs 指向了错误的 tests/ 目录层级。
- 确认已激活项目虚拟环境，并执行
pip install pytest pytest-mock - 在工作区
.vscode/settings.json中显式声明："python.testing.pytestArgs": ["--rootdir=.", "tests"]
（注意--rootdir要和实际tests/相对位置匹配） - 重启 VSCode 或点击状态栏上的
Python Test→Reload Tests
Generate test 生成的代码为什么总报 NameError: name 'xxx' is not defined
插件默认只生成测试函数体，不会自动加 import。比如你对 utils.py 里的 parse_json 生成测试，它会写 def test_parse_json(): parse_json(...)，但没加 from utils import parse_json。
这不是 bug，是设计取舍：插件无法 100% 推断你要 import 的模块路径（尤其跨包时）。所以生成后必须人工补 import 行，否则运行就崩。
- 生成后立刻检查第一行是否含
import或from ... import - 如果被测函数在
src/myapp/core.py，而测试文件在tests/test_core.py，推荐用绝对导入：from src.myapp.core import parse_json
- 避免相对导入（如
from ..core import parse_json），pytest运行时容易因启动路径不同而失败
用 Test Explorer UI 插件跑单个测试比终端快在哪
它不是靠“更快”，而是靠“跳过无关步骤”：不重新加载整个 pytest session，不扫描全部 test_*.py 文件，直接调用 pytest ::test_name 子命令。实测在 200+ 测试的项目里，单测执行耗时从平均 800ms 降到 120ms 左右。
但这个加速有前提——你得让插件知道哪些文件是“测试文件”。它默认只认 test_*.py 和 *_test.py，如果你用 spec.py 或 it.py 命名，就得改配置：
- 在
settings.json加："python.testing.pytestArgs": ["--python-files=test_*.py *_test.py spec.py"]
- 确保测试函数名符合
pytest发现规则（test_开头 或_test结尾） - 右键测试节点选
Debug Test时，会自动附加调试器，不用手动设断点再跑终端命令
为什么改了源码，Test Explorer 不自动刷新测试列表
它只监听 test_*.py 文件变化，不监听被测源码。也就是说，你改了 service.py，左边测试树不会变；但你改了 test_service.py，它会立刻重载该文件下的测试项。
这导致一个典型误操作：修完 bug 后直接点绿色三角运行，结果跑的还是旧版测试逻辑——因为测试文件本身没动，缓存没清，pytest 读的仍是旧字节码。
- 每次修改源码后，手动点测试树右上角的
Refresh图标（两个箭头组成的圆圈） - 或者用快捷键
Ctrl+Shift+P→ 输入Python: Discover Tests强制重扫 - 更稳妥的做法：把
pytest --lf（last-failed）加进配置，这样即使列表没刷新，至少能确保上次失败的测试被重新执行
真正麻烦的是跨文件依赖——比如 test_a.py 里 import b，而你刚改了 b.py，这时候不刷新，测试可能静默通过，但实际逻辑已失效。这种链路没法靠插件自动感知，只能靠人盯。
