一个功能不多的小 app,能构建、能运行,周边检查也都过得去——直到一条自动化检查问了它一个问题:有没有任何测试,把它的核心流程从头到尾驱动过?
答案是没有。不是测试挂了,是那个测试从未存在过。
值得记下的是“隐形”的机制:绿色只证明“没有断言失败”,而“根本没有检查”产出的同样是绿色。构建通过说明每个零件都造出来了,不说明任何一条流程能走通。而且核心流程越简单,越没人给它写测试——“就这么点事,怎么会坏”——可它恰恰是整个 app 存在的理由。零件查得再细,也替不了主干被完整走通过一次。
修法有个承重的顺序:
1. 先立骨架:建一个真正驱动端到端主路径的测试——启动 app,走完那条路径,断言用户可见的终态。先有空壳也行;骨架是“可被检查的单元”,没有它,断言写得再细也没有载体。 2. 再填真实步骤:让断言落在用户看得见的终态上,而不是某个函数的返回值上。 3. 最后让“缺失”本身变成失败:把“核心流程测试存在且在跑”列为一条检查项。流程会改,测试会跟着改,但“必须存在”不变——下次它消失时是红的,而不是无声的。
一分钟自检:打开测试目录问一句——有没有一个测试,启动 app、走完它存在的那个理由、断言终态?把那个测试整个删掉,会有任何检查变红吗?不会的话,你的核心流程从来没被执行过,只被你的拇指执行过。
完成度的证据,从来不是“每个零件都查过”,而是“主干被走通过一次,而且证据找得到”。