vscode不执行测试，仅调度和展示结果；真正运行测试的是配置的命令（如pytest、dotnet test），关键在于让vscode正确调用该命令并稳定反馈。
VSCode 本身不执行测试脚本，它只调度、展示和整合结果；真正跑测试的是你配置的命令（如 pytest、dotnet test、newman run），VSCode 只是把终端、任务、测试资源管理器串起来。关键不是“怎么教 VSCode 跑测试”，而是“怎么让 VSCode 正确调用你的测试命令并稳定反馈”。
为什么 python -m unittest discover 找不到测试文件
这是最常卡住的第一步。VSCode 的 Python 扩展默认用 python -m unittest discover 扫描，但它严格依赖目录结构和命名规则：
- 默认只查当前工作区根目录下，以
test*.py命名的文件 ——user_test.py或tests/test_login.py都不会被自动发现，除非显式指定 - 如果项目有
tests/子目录，必须在 VSCode 设置里改python.testing.unittestArgs，例如：["-s", "tests", "-p", "test_*.py"] -
__init__.py缺失会导致子包无法导入，哪怕文件存在也会静默跳过 ——tests/和tests/unit/都得有它 - VSCode 启动方式影响
$PATH：从 macOS 图形界面点开 VSCode，python命令可能根本不在环境变量里，建议在tasks.json中用绝对路径，比如/opt/homebrew/bin/python
dotnet test 在 VSCode 里报错 “No test assemblies found”
Q# 或 C# 测试项目常见此问题，根源不是代码写错，而是构建产物没生成或路径没对上：
- 必须先执行
dotnet build，否则dotnet test找不到.dll—— VSCode 不会自动帮你构建，除非你在tasks.json里配了"dependsOn": "build" - 测试项目必须引用主项目：检查
.csproj文件里是否有<projectreference include="..\MyQuantumProject\MyQuantumProject.csproj"></projectreference> - Q# 测试需指定模拟器：命令得带
--filter FullyQualifiedName~QuantumSimulator，否则 MSTest 默认跑在 .NET 运行时上，不兼容量子操作 - VSCode 的测试资源管理器缓存旧状态：删掉
bin/和obj/目录，再重启 VSCode 窗口
保存即运行测试？小心 runOn: "save" 的三个硬限制
VSCode 的 tasks.json 支持 "runOn": "save"，但极易失效，不是配置错，而是触发逻辑被忽略：
- 只对属于内置组的任务生效：
"group": "test"可以，"group": "my-test"完全无效 -
"type": "shell"是唯一稳妥选择；"type": "process"在 Windows 上遇到空格路径（如C:\Program Files\...）大概率失败 - 任务必须“可感知运行中状态”：比如
pytest一次性跑完就退出，VSCode 认为它已结束；而nodemon或watchexec持续运行，需配"isBackground": true和匹配启动日志的problemMatcher，否则第二次保存会再启一个进程
Postman 集合在 VSCode 里断言失败，但 GUI 里通过
根本原因：newman 不支持 Postman GUI 里能用的全部 API。Tests 脚本看似一样，运行时环境完全不同：
-
pm.*可用，但console.log、require()、fs.readFileSync全部报ReferenceError或TypeError - 环境变量加载格式必须是 Newman 兼容的
.env.json，不是 Postman 导出的.json环境文件 —— 后者含values数组，前者是扁平 key-value 对象 - 集合 JSON 不能手动编辑：VSCode 的 JSON 格式化（
Shift+Alt+F）会删掉 Postman 允许的 trailing comma，或把注释转成非法语法，导致newman validate直接失败 - 断言报错信息极简：
TypeError: Cannot read property 'length' of undefined几乎 100% 是集合结构损坏，不是脚本逻辑问题
真正的难点不在写测试，而在让 VSCode 准确识别你的测试入口、正确传递上下文、并在出错时给出可定位的线索。每个框架（Python/unittest、.NET/MSTest、newman、Playwright）都绕不开工作目录、环境变量、构建产物路径这三座墙。跨过去靠的不是文档复制，是看懂错误输出里那行真实的 shell 命令，然后手动在集成终端里重放一次。
