最安静的失败是全绿的失败。
一个组件测试齐全、看板全绿的 app,可能从第一次构建起就没有一条测试真正执行过它的核心流程——那个 app 存在的理由本身。发现它的方式很能说明问题:不是哪条测试红了,而是一条存在性检查报了缺失。测试挂掉至少有声音;测试不存在,是完全的静音。
为什么这种缺口能活下来:绿色证明的是"每个零件都能工作",从来不证明"产品能工作"。核心流程没有覆盖时,没有任何一层会报错——它只是不说话,而沉默和通过在结果页上长得一模一样。
修法,顺序是承重的: 1. 先搭空骨架。生成一个空的核心流程测试文件,把"缺失"从没人想起来的念头降级成机械可见的事实:文件在不在,一眼可查。 2. 再填真实流程。从冷启动走到核心路径的完成态——不是"某个界面出现了",而是 app 存在是为了做的那件事,端到端走通。 3. 最后让缺失本身变红。加一条检查:核心流程测试不存在就失败。否则下一个项目还会以同样的方式静默通过。
顺序为什么重要:一上来就写"真正的测试",多半会滑回组件级断言;骨架先行先解决"有没有",再解决"对不对"。
一分钟自检:打开你的 UI 测试 target,搜一条把核心路径驱动到完成的测试。命中为零的话,你那块绿板认证的是零件,不是产品。