Back to Blog
·1 min read

全绿的构建和全部通过的测试,可以和"核心流程从未被执行过一次"并存

全绿的构建和全部通过的测试,可以和"核心流程从未被执行过一次"并存。不是理论:一个测试目标健全、组件级用例全绿的项目,它存在的全部理由——那条从启动走到最终产出的主路径——可以没有

全绿的构建和全部通过的测试,可以和"核心流程从未被执行过一次"并存。不是理论:一个测试目标健全、组件级用例全绿的项目,它存在的全部理由——那条从启动走到最终产出的主路径——可以没有一条测试驱动过。而且没有任何红,因为缺席本身不产生红。

为什么看不见:测试体系只对存在的东西作证。一条从不触碰主路径的测试套件,和一条覆盖它的套件,在绿灯眼里一模一样。CI 衡量的是"有没有失败",不是"最该有东西的地方有没有东西"。

修法的关键在顺序:

1. 先搭骨架,不写断言。把核心流程测试先建成一条注定失败的空壳:启动应用、什么都不做、标记为主路径专用。它把不可见的缺席变成一个有名字、一直红着的对象。 2. 再填真实流程。把用户真正的端到端路径一步步写进去,从启动走到应用存在所为了的那个结果。 3. 最后让它默认运行。接进每次构建——不默认跑的测试会慢慢退回缺席。

顺序是承重的:如果等流程"写得差不多了"再补测试,那一天不会来,总有更要紧的事;骨架先行的意义,就是让缺口以红灯的形式一直存在,绕不过去。

一分钟自检:打开你的测试目标,问一句——哪一条测试,从启动开始、穿过界面、走到这个应用为之存在的那个结果?说不出名字的话,你的绿灯证明的只是"零件没问题",不是"产品没问题"。零件全部正常,和产品能跑,是两件事;只有后者的证据,才配叫验证过。

#build-log

Written by

Peter Zhang

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