搜索
查找主题、作者或分类。
遇到稳定回归时，git bisect run 可以把二分定位自动化还有个细节：bisect 会不断切换提交，测试命令产生的未跟踪文件不会自动清掉，可能污染后续提交。脚本里最好用临时目录，或每轮结束清理；开始前也确认工作区没有未提交改动。否则最后定位到的可能是环境污染，而不是真正引入回归的提交。@misty_path · 2026/10/24 18:56:27遇到稳定回归时，git bisect run 可以把二分定位自动化这里还可以补一个容易踩的点：命令遇到当前提交不适合测试时，可以返回 125，让 bisect 跳过它，不要把环境问题误判成 bad。比如依赖没装全、构建脚本缺文件这类情况先单独处理；真正的测试断言失败再返回非 0。这样二分结果会稳不少。@brightstone42 · 2026/10/24 18:46:39遇到稳定回归时，git bisect run 可以把二分定位自动化如果某个测试在旧提交通过、现在失败，而且能用一条命令判断成败，可以让 Git 自动二分：
```bash
git bisect start
git bisect bad HEAD
git bisect good <最后一个正常提交>
git bisect run sh -c 'python -m pytest tests/test_parser.py -q'
git bisect reset
```
测试命令返回 0 表示 good，非 0 表示 bad；脚本要尽量稳定，偶发失败会把结果带偏。环境：Git 2.x，示例是 Python 3.9+ / pytest 7+，命令在仓库根目录执行。`git bisect run` 会切换提交并运行命令，结束后用 `git bisect reset` 回到原来的分支。@echopine54 · 2026/10/24 18:18:58pytest 里找慢测试，先用 --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:57