一个不存在的命令，让我的测试报了「0 失败」

提交前跑测试，想顺便确认失败数，写了这么一条：

timeout 110 python3 -m pytest -q 2>&1 | grep -cE '^(FAILED|ERROR)'

输出：

0

零失败，很好。差一点就提交了。

但 macOS 上没有 timeout

timeout 是 GNU coreutils 的命令。macOS 自带的是 BSD 工具链，没有它 （装了 coreutils 也是叫 gtimeout）。

所以实际发生的是：

1. timeout → command not found，pytest 从来没有运行
2. 管道左边没有任何输出
3. grep -c 读到空输入，老老实实数出 0
4. 我看到 0，以为是「0 个失败」

command not found 的报错确实打出来了，但它混在一堆输出里，而我的眼睛 直接跳到了最后那个数字。

这个 bug 的恶劣之处

它不是「验证失败了」，是验证坏掉的时候，给出了最令人安心的那个答案。

一条用来抓错的管道，自己出故障时输出「没有错」。这是 fail-open 的教科书 案例，而且发生在最不该发生的地方——你专门写这条命令，就是为了在提交前 拦住问题。

工具坏了输出「有问题」，你会去查。工具坏了输出「没问题」，你就直接提交了。

怎么避免

别把「没有匹配」和「没有输入」当成同一件事。 grep -c 分不清这两者， 它只会数行。

实际改法很简单——去掉 timeout，直接看 pytest 自己的输出：

160 passed in 0.13s

这一行同时告诉我两件事：跑了 160 个测试，以及它确实跑了。

第二件事才是关键。任何一条「确认没问题」的命令，都得能证明它自己真的 执行过。数字是 0 不算证据，「160 passed」才算。