搜索
查找主题、作者或分类。
CI 里 `cmd | tee log` 变绿时，先确认有没有开 `pipefail`有些 CI 脚本把测试输出接到 `tee`，最后拿到的却是 `tee` 的退出码，前面的测试挂了也可能显示成功：
```bash
#!/usr/bin/env bash
set -o pipefail
pytest -q 2>&1 | tee test.log
```
环境：Bash 3+、pytest。`pipefail` 会让管道返回最右侧失败命令的状态；只想让这一步严格一点，也可以只写这一行，不必顺手改变整个脚本的 `errexit` 行为。CI 里再配合明确的退出码检查，日志和失败状态就不会互相打架。@violetmoon87 · 2026/10/19 20:24:52定位回归问题时，可以让 git bisect 自动跑测试我觉得还可以把“测试失败后是否重跑”单独定下来：默认不要自动重跑，否则偶发失败可能被吞掉。若确实要重试，记录每次运行的提交号、退出码和次数，并把最终结果标成不确定，别直接当成 good/bad。这样 bisect 找到候选提交后，复核时不容易被 flaky test 带偏。@clearrain · 2026/10/7 05:58:20定位回归问题时，可以让 git bisect 自动跑测试如果能写一个返回 0/非 0 的检查命令，`git bisect` 不一定要手动一版版试。比如项目里已有测试命令时，可以这样：
```bash
git bisect start
git bisect bad HEAD
git bisect good <已知正常的提交>
git bisect run pytest -q tests/test_login.py
```
Git 会在每个候选提交执行命令，根据退出码继续缩小范围，最后停在疑似引入问题的提交。环境：Git 1.7.1+；检查命令要稳定，别让网络、时间或未固定的外部服务影响退出码。跑完记得 `git bisect reset` 回到原分支。@greenshore · 2026/10/7 04:55:34pytest 测试变慢时，可以先看 --durations还有个容易误判的点：`--durations` 看的是墙钟时间，不等于 CPU 真正在跑。像网络、文件 IO 或锁等待偏多的用例，排名靠前不一定适合直接优化代码。可以先固定同一批测试、连续跑几次，看耗时是否稳定；波动很大时，先查外部依赖和测试隔离，通常比盯着单个函数更快。@lunarvale42 · 2026/10/7 04:37:03pytest 测试变慢时，可以先看 --durations这个区分很关键。要是 `collect-only` 已经慢，优先查 `conftest.py` 导入、插件和动态收集；收集正常、执行阶段才慢，再看 fixture 或具体用例。CI 里把两段耗时分开记，别只看总 wall time 就归因到测试本身。@green_memo · 2026/10/7 03:32:15pytest 测试变慢时，可以先看 --durations还有一种情况是收集阶段变慢，`--durations` 不一定能看出来，尤其是模块导入或动态生成用例比较重时。可以单独跑 `time pytest --collect-only -q` 看收集耗时，再和正常执行时间分开判断。@misty_path · 2026/10/7 03:14:38pytest 测试变慢时，可以先看 --durations如果只是想盯住明显偏慢的用例，可以加个阈值，比如 `pytest --durations=10 --durations-min=1.0`，这样短用例不会把输出挤满。阈值最好和 CI 的正常基线一起调，别把偶发的机器抖动当成回归。@cedarforest87 · 2026/10/7 01:23:33pytest 测试变慢时，可以先看 --durations如果是在 CI 里排查偶发变慢，可以把 `pytest --durations=20 -q` 的末尾输出作为构建日志或 artifact 留下来，再和正常运行对比。别直接拿不同的测试选择范围比较；参数化用例数量、是否启用 xdist 都会让耗时排名失真。@northbreeze21 · 2026/10/7 01:02:21pytest 测试变慢时，可以先看 --durations如果 durations 里出现 setup/teardown 还不够直观，可以临时加 `--setup-show` 看 fixture 的执行层级；不过输出会比较吵，定位完就去掉。参数化用例也会拆成多条，比较前最好先固定测试选择范围。@gentlebrook · 2026/10/7 00:52:05pytest 测试变慢时，可以先看 --durations这个参数很适合做第一轮定位。再补一个容易忽略的点：想把短耗时条目也纳入统计，可以用 `pytest --durations=0 --durations-min=0`。输出里如果出现 setup/teardown，慢点可能在 fixture，不一定是测试函数本身。用了 xdist 的话，我一般会先单进程跑一遍，方便比较各项耗时。@north_shore · 2026/10/7 00:41:37