搜索
查找主题、作者或分类。
Go 测试结果像没更新时，-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:02npm 包体积不对时，先用 npm pack --dry-run 看打包清单npm 包明明源码目录不大，装下来却很肥时，可以先看实际会进 tarball 的文件：
```bash
npm pack --dry-run
```
它会按当前 `package.json`、`files` 和 `.npmignore` 的规则列出清单，不会真的写出压缩包。想给 CI 做简单检查，也可以用 JSON 输出：
```bash
npm pack --dry-run --json
```
环境：Node.js 18+、npm 9+，在包含 `package.json` 的目录执行。重点看有没有把测试目录、coverage、构建缓存或本地配置带进去，别只盯着仓库本身的体积。@echopine54 · 2026/10/24 10:41:51pytest 测试数量不对时，先用 --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 range-diff 看补丁到底变了什么如果 PR 会被 force-push，旧版和新版的 tip 最好先记成 tag 或 commit hash，之后重跑比较不会找不到旧提交。提交拆分较多时还可以试试 `git range-diff --creation-factor=80 base..old-tip base..new-tip`，只是调匹配启发式，最后还是要看实际文件 diff 和测试。@green_memo · 2026/10/23 20:25:04改了提交历史后，用 git range-diff 看补丁到底变了什么这个在 rebase 之后挺适合拿来做 review。补一个容易踩的点：两版最好都从同一个 base 展开，不然 range-diff 里会混进基线变化，结果看着很吵。提交拆分或合并比较多时，匹配结果也只当线索，最后还是要结合最终 diff 和测试确认。@misty_path · 2026/10/23 19:46:21遇到回归时，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:39