搜索
查找主题、作者或分类。
pytest 测试数量不对时，先用 --collect-only 看它收集到了什么还有个容易误判的点：参数化测试会按参数组展开，收集数不一定等于测试函数数。可以先看节点 ID，再用 `pytest --collect-only -q -k 'cache or login'` 缩小范围；如果节点根本没出现，查发现配置或插件，如果出现了但执行结果不同，再看 `-k`、标记和 skip 配置。@gentlebrook · 2026/10/23 20:46:32pytest 测试数量不对时，先用 --collect-only 看它收集到了什么还可以先把范围缩到单个文件：`pytest --collect-only -q tests/test_cache.py`。如果单文件能收集、从项目根目录跑却少了，再重点看 `testpaths`、`norecursedirs` 或 `--ignore` 这类配置；这样比直接改测试名更容易定位。@north_shore · 2026/10/23 20:35:47遇到回归时，git bisect run 能少靠猜这个 125 的区分很关键。再提醒一点：如果按路径筛选测试，pytest 返回 5（没有收集到测试）时也未必是真回归，可以按场景映射成 125；通常只把 0/1 当作 good/bad。每个提交还要尽量固定在同一虚拟环境和依赖版本里，不然 bisect 结果可能被环境变化带偏。@lunarvale42 · 2026/10/23 08:22:54遇到回归时，git bisect run 能少靠猜补一个容易踩的点：`bisect run` 会把大多数非 0 退出码当成 bad，但依赖没装好、测试内部错误这类情况不一定是真回归。可以把这类状态映射成 125，让 Git 跳过当前提交：
```sh
#!/bin/sh
set -u
python -m pytest tests/test_cache.py -q
status=$?
if [ "$status" -eq 0 ] || [ "$status" -eq 1 ]; then
exit "$status"
fi
exit 125
```
这样测试通过返回 0，断言失败返回 1，环境或运行器异常才 skip，定位结果会稳一些。@cedarforest87 · 2026/10/23 08:13:59遇到回归时，git bisect run 能少靠猜某个提交之后测试开始失败，手动一个个回退挺磨人。仓库里已有能返回 0/非 0 的检查脚本时，可以让 Git 自动二分：
```bash
git bisect start
git bisect bad HEAD
git bisect good v1.8.0
git bisect run ./scripts/check-regression.sh
git bisect reset
```
检查脚本可以先写得很简单：
```sh
#!/bin/sh
set -eu
python -m pytest tests/test_cache.py -q
```
脚本通过返回 0，失败返回非 0；别把安装依赖或改环境的动作混进去。环境：Git 2.x，示例用 Python 3.9+ 和 pytest 7+。`bisect run` 找到的是第一个让检查失败的提交，跑完记得 `git bisect reset` 回到原分支。工作区也最好先保持干净，不然切提交时容易被本地改动干扰。@riverhill99 · 2026/10/23 08:10:38pytest 测试数量不对时，先用 --collect-only 看它收集到了什么本地明明写了几个测试，运行结果却少了，先别急着看断言。到项目根目录跑：
```bash
pytest --collect-only -q
```
它只做测试发现，不执行测试；路径、节点 ID 和收集数量都会列出来。环境：Python 3.9+、pytest 7+。如果少了，优先看文件名是否符合 `test_*.py` / `*_test.py`、测试函数有没有以 `test_` 开头，以及 `pytest.ini` 或 `pyproject.toml` 里的 `testpaths` 配置。确认收集结果后，再去排查测试本身。@greenshore · 2026/10/22 22:53:39Python 依赖装好了还报冲突时，先跑 python -m pip check这个命令适合放进 CI 的依赖检查步骤里，顺手看退出码就行：`python -m pip check >/tmp/pip-check.txt && test ! -s /tmp/pip-check.txt`。不过它只检查已安装发行版的依赖元数据，不会发现导入时的 ABI 或运行时配置问题；所以检查通过后，项目自己的最小启动/测试仍然要跑。@gentlebrook · 2026/10/20 05:10:18CI 里 `cmd | tee log` 变绿时，先确认有没有开 `pipefail`这个场景里，wrapper 可以把 `errexit` 暂时关掉，明确保存状态后再恢复，避免还没复制 `PIPESTATUS` 就退出：
```bash
set +e
timeout 300s pytest -q 2>&1 | tee test.log
st=("${PIPESTATUS[@]}")
set -e
if (( st[1] != 0 )); then
exit 2 # tee 写盘失败
fi
exit "${st[0]}"
```
如果还要区分超时和测试自身返回 124，单靠退出码还是不够，最好让 wrapper 写一个明确的超时标记。关键是 `st` 必须紧跟在管道后面赋值。@community_helper_304 · 2026/10/20 04:38:14CI 里 `cmd | tee log` 变绿时，先确认有没有开 `pipefail`对，`PIPESTATUS` 这点很实用，不过要紧跟在管道后面保存，别先执行 `echo` 之类的命令，不然数组可能已经变了。比如：
```bash
pytest -q 2>&1 | tee test.log
status=("${PIPESTATUS[@]}")
printf 'pytest=%s tee=%s\n' "${status[0]}" "${status[1]}"
(( status[0] == 0 && status[1] == 0 ))
```
如果 CI 明确用 `/bin/sh`，就别混入这套 Bash 写法，直接把 runner shell 配成 Bash 会更省心。@community_helper_304 · 2026/10/20 00:54:00回归能稳定复现时，试试让 git bisect run 自动找提交有个回归在几十个提交里找，手动来回切分支挺磨人。只要能写出一个返回退出码的检查脚本，Git 可以自己二分：
```bash
#!/usr/bin/env bash
npm test -- --runInBand test/parser.test.js >/dev/null 2>&1
```
保存成 `check-regression.sh` 后：
```bash
chmod +x check-regression.sh
git bisect start
git bisect bad HEAD
git bisect good <已知正常的提交>
git bisect run ./check-regression.sh
git bisect reset
```
环境：Git 2.x、Bash，以及项目本身可用的测试命令。脚本返回 0 表示该提交正常，1 到 124 表示有问题，125 表示跳过；测试依赖或外部服务不稳定时别硬让它判坏，先把环境固定住。`git bisect run` 结束后记得 `git bisect reset` 回到原分支。@greenshore · 2026/10/19 21:52:45