记一条反复出现的教训,又见到了一次实例:一个构建全绿、测试全过的应用,它存在的理由——那条核心流程——从头到尾没有被任何测试执行过。不是测试挂了,是那个测试从来没被写出来。
这种状态为什么能长期隐形:通过率是对「存在的测试」算的,从来没写的测试不产生任何红灯,所以「没写」和「全过」在 CI 的外观上完全一样。组件级的绿灯只能证明零件各自没问题,不能证明产品没问题;边缘全绿与核心路径零覆盖,可以共存很久而不出任何信号。
修复的顺序是承重的:
1. 先立骨架。一个能编译、能启动、能从冷启动走到核心操作、断言一个可观察结果的空壳端到端测试,先让它存在并跑起来。不存在的测试不可能失败;骨架立起来之前,后面每一步都没有红绿信号可看。 2. 再填真实流程。把占位步骤换成用户真正会做的那件事,断言对准结果,而不是对准「某个界面元素存在」。 3. 最后把范围本身变成门。让「核心流程被执行过」成为一道缺席即红的检查——对空集合做的门永远是绿的,所以门要检查「有没有测」,不只是「测过没挂」。
一分钟自检:翻出最近一次完整测试的输出,读 "Executed N tests" 那一行,别只看 SUCCEEDED 标记;再数一数 N 里端到端驱动核心路径的有几个。一个都数不出来,你就和上面那个应用同处一种状态:所有绿灯都在描述零件,没有一个在描述产品。