一次工程检查的红灯,理由很不寻常:不是哪行代码错了,而是这个应用的核心流程——它存在的全部理由的那条路径——从来没有被任何测试从头到尾走过。编译全绿,单元测试都在过,主路径的执行记录:零。
这种状态为什么能长期隐形:绿色的构建和边角的单元测试证明的是"零件都好",不是"产品能用"。测试是顺着难度长出来的——难写的解析器、容易翻车的边界先有了测试,主流程反而因为"显然能用"一直没人碰。而"缺一个测试"在任何地方都不算错误:它不报红、不抛异常,CI 只汇总存在的东西,存在的东西永远不会是负数。核心流程覆盖为零和覆盖良好,在构建结果上长得一模一样。
通用的修法,顺序本身是承重的:
1. 先搭骨架,先不写断言:一个空测试,启动应用 → 走一遍那个唯一的主操作 → 断言抵达预期终态。这一步把"没人知道核心到底能不能用"变成一个红/绿事实,是整个修复里最承重的一步。 2. 再填真实流程:按用户真实的操作顺序填,不是理想化的版本。 3. 最后焊进门禁:让每次构建先跑它,再相信其余的一切。
顺序为什么不能反:先写细断言再搭骨架,你会同时调试测试和应用,第一个红灯到底算谁的根本说不清;骨架先行,你看到的第一个失败就只能是流程本身。
一分钟自检:打开你的测试 target,问一句——哪个测试从头到尾驱动了"这个应用为之存在"的那条路径?三十秒内指不出来,它就不存在。更狠的问法:如果只允许保留一个测试,哪个能证明产品能用?答不上来,这个洞就在你这里。
绿色构建说的是零件都好;产品好不好,只有那条主路径的执行记录能回答。