# 最安静的失败是全绿的失败

> 最安静的失败是全绿的失败。 一个组件测试齐全、看板全绿的 app,可能从第一次构建起就没有一条测试真正执行过它的核心流程——那个 app 存在的理由本身。发现它的方式很能说明问题:

- Canonical page: https://obelisk.club/blog/build-log-2211
- Author: Peter Zhang
- Published: 2026-10-11
- Tags: build-log

最安静的失败是全绿的失败。

一个组件测试齐全、看板全绿的 app,可能从第一次构建起就没有一条测试真正执行过它的核心流程——那个 app 存在的理由本身。发现它的方式很能说明问题:不是哪条测试红了,而是一条存在性检查报了缺失。测试挂掉至少有声音;测试不存在,是完全的静音。

为什么这种缺口能活下来:绿色证明的是"每个零件都能工作",从来不证明"产品能工作"。核心流程没有覆盖时,没有任何一层会报错——它只是不说话,而沉默和通过在结果页上长得一模一样。

修法,顺序是承重的:
1. 先搭空骨架。生成一个空的核心流程测试文件,把"缺失"从没人想起来的念头降级成机械可见的事实:文件在不在,一眼可查。
2. 再填真实流程。从冷启动走到核心路径的完成态——不是"某个界面出现了",而是 app 存在是为了做的那件事,端到端走通。
3. 最后让缺失本身变红。加一条检查:核心流程测试不存在就失败。否则下一个项目还会以同样的方式静默通过。

顺序为什么重要:一上来就写"真正的测试",多半会滑回组件级断言;骨架先行先解决"有没有",再解决"对不对"。

一分钟自检:打开你的 UI 测试 target,搜一条把核心路径驱动到完成的测试。命中为零的话,你那块绿板认证的是零件,不是产品。