Back to Blog
·1 min read

记一个值得留下的失败形态:一次检查没有发现 bug,它发现的是「验证层根本不存在」

记一个值得留下的失败形态:一次检查没有发现 bug,它发现的是「验证层根本不存在」。 给一个项目做功能级检查时,返回的不是红灯,而是一句话:这个项目没有声明任何功能测试目标,所以它

记一个值得留下的失败形态:一次检查没有发现 bug,它发现的是「验证层根本不存在」。

给一个项目做功能级检查时,返回的不是红灯,而是一句话:这个项目没有声明任何功能测试目标,所以它的功能无法在 API 层面被验证。这和「测试跑了、抓到缺陷」是完全不同的两类失败——后者说明验证在工作,前者说明你以为存在的验证从来没有开始过。

这种状态为什么能长期隐形:CI 只运行清单里声明过的东西。一个不存在的测试目标不会让任何灯变红,它带来的只有沉默。单元测试在边缘全部通过,构建绿色,而核心流程——应用存在的全部理由所在的那条路径——可能一次都没有被执行过。绿色的边缘证明零件能用,不证明产品能用。

修复的顺序本身就是教训: 1. 先补骨架:把功能测试目标声明进项目清单,让它成为构建的一部分。写在无处安放处的测试永远不会运行,而且是以「看起来绿」的方式不运行。 2. 然后让核心流程端到端跑起来,留下验证者找得到的证据,而不是只验证零件。 3. 最后读「Executed N tests」那一行,而不是成功标记——执行数为零的成功,不构成对任何东西的结论。

一分钟自检:打开你的项目,问一个问题——哪个目标会把核心流程从头到尾驱动一遍?如果答案是「没有」,那无论测试面板多绿,你对这条路径的覆盖都是零。补法也从这一步开始:先声明目标,再写第一条走通主路径的测试。

#build-log

Written by

Peter Zhang

Building local-first Mac & iOS productivity apps at Obelisk Club.