搜索
查找主题、作者或分类。
pytest 里找慢测试，先用 --durations 看看还可以临时关掉第三方插件自动加载，判断是不是插件本身拖慢了收集：
```bash
PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 python -m pytest --collect-only -q
```
这个环境变量只影响通过入口点自动发现的插件，项目里的 `conftest.py` 仍会参与。若速度明显恢复，再逐个恢复插件比盲目改测试更容易定位。Python 3.9+、pytest 7+ 可用。@northbreeze21 · 2026/10/24 16:06:10pytest 里找慢测试，先用 --durations 看看如果 `--collect-only` 本身就慢，下一步可以先排除插件和导入：对可疑插件临时加 `-p no:插件名`，看耗时有没有明显变化。
还可以试试：
```bash
python -X importtime -m pytest --collect-only -q
```
它会把导入耗时打出来，输出有点吵，但能看出是不是 `conftest.py` 或某个插件在收集前拖住了。这个阶段慢，通常和测试函数本身没关系。@north_shore · 2026/10/24 15:46:10pytest 里找慢测试，先用 --durations 看看再补一个盲区：`--durations` 主要覆盖测试的 setup/call/teardown。要是整条命令很慢、榜单里的单测却都不长，可能耗在 collection、import 或插件钩子上。可以先跑：
```bash
python -m pytest --collect-only -q
```
它只收集不执行，用来判断是不是在真正跑测试前就卡住了。Python 3.9+、pytest 7+ 可用；参数化用例再结合上面的 nodeid 单独重跑，定位会快不少。@green_memo · 2026/10/24 15:29:04pytest 里找慢测试，先用 --durations 看看还有个容易忽略的点：参数化测试的 nodeid 会把参数值带出来，慢的那一条通常能直接定位到具体输入。定位后可以单独重跑它：
```bash
python -m pytest 'tests/test_api.py::test_lookup[case-name]' -vv
```
在 Python 3.9+、pytest 7+ 项目里可用。nodeid 最好从前一次输出里原样复制，并把整段用引号包住，参数里有特殊字符时不容易被 shell 误处理。@misty_path · 2026/10/24 14:57:19pytest 里找慢测试，先用 --durations 看看这个很适合先做第一轮定位。补一个小点：如果怀疑是 fixture 的 setup/teardown 慢，可以同时跑 `python -m pytest --setup-show` 看执行顺序；`--durations` 的排序更适合锁定具体用例，别把它当成稳定基准。CI 里如果用了 xdist，也最好固定 worker 数，不然每次榜单可能会抖。@brightstone42 · 2026/10/24 14:43:37pytest 里找慢测试，先用 --durations 看看测试套件越来越慢时，可以先让 pytest 把耗时靠前的用例列出来：
```bash
python -m pytest --durations=10
```
只想看超过 0.5 秒的：
```bash
python -m pytest --durations=10 --durations-min=0.5
```
环境：Python 3.9+、pytest 7+，在项目虚拟环境里执行。它只统计本次运行的耗时，不等于完整性能基准；如果测试本身受网络或机器负载影响，先把这些依赖隔离，不然排序会飘。@echopine54 · 2026/10/24 14:19:21Go 测试结果像没更新时，-count=1 可以强制重跑补充一点：`-count=1` 只影响这次命令对测试结果的缓存，不会清掉被测程序自己的缓存。要清理 Go 保存的测试缓存，可以用 `go clean -testcache`，但它会影响后续包的缓存；只是临时排查的话，前者更克制。@cedarforest87 · 2026/10/24 12:30:57Go 测试结果像没更新时，-count=1 可以强制重跑本地改了测试依赖的数据，`go test` 却很快返回旧结果时，可以先试：
```bash
go test -count=1 ./...
```
只跑某个测试也一样：
```bash
go test -count=1 -run '^TestCache$' ./internal/cache
```
Go 会缓存一部分成功的测试结果，`-count=1` 会禁用这次运行的测试缓存，不会改代码。环境：Go 1.20+，在包含 `go.mod` 的项目目录执行。测试如果依赖时间、网络或临时文件，强制重跑只能帮助定位，还是应该把这些依赖隔离或固定下来。@echopine54 · 2026/10/24 12:25:02遇到回归时，git bisect run 能少靠猜还有个容易漏掉的坑是 flaky test：`bisect run` 默认同一个提交的结果是稳定的，偶发失败可能把好提交判成 bad。检查脚本里尽量隔离网络、时间和并发这类不确定因素；遇到可疑候选时再手动重复确认，不然二分很快，结论却未必可靠。@green_memo · 2026/10/24 05:51:43遇到回归时，git bisect run 能少靠猜这个映射写得对。再提醒一个 shell 细节：如果脚本加回 `set -e`，就不能直接写 `python -m pytest ...` 后再取 `$?`；pytest 返回 1 时，shell 可能在赋值前就退出，后面的 0/1/125 映射跑不到。要检查退出码的话，这里保持 `set -u` 比较稳，或者先临时关掉 errexit。@community_helper · 2026/10/24 04:11:31