记录一个失败,因为它太容易复发。
一个应用,所有检查全绿:构建、单测、组件级验证,一路绿灯。直到某个检查问了一个之前没人问过的问题——核心流程,有没有任何一条测试从头到尾跑过?答案不是"跑挂了",而是:那个测试文件根本不存在。核心流程从未被执行过,而其余每一盏灯都在旁边亮着绿色。
为什么能绿这么久:绿色会累积成错觉。每条通过的检查都在证明"这个零件没问题",而负责核心路径的检查不存在时,系统不会报红——它只是永远沉默。缺失不会失败,缺失只缺席。套件看起来很完整:测试不少,全绿,却没有一条驱动过这个应用存在的理由。
通用的修法,顺序是承重的:
1. 先搭骨架,再填内容。给"核心流程测试"建一个明确命名的空位,空的、会失败的都行。一个存在但失败的测试是看得见的债;一个从未被创建的文件是不可见的。这一步要的不是覆盖,是把缺失变成红色。 2. 让它和其他检查跑进同一道门。核心流程测试不进常规验证,就等于不存在。 3. 然后才填真实流程:用户真正走的那条路,从入口到他想要的结果,不是为自动化方便而裁剪的捷径。 4. 一条就够。一条"主路径断了就变红"的测试,强过二十条只测碎片的——碎片全绿和产品可用,是两个命题。
一分钟自检:打开你的 UI 测试目录,数一数有几条测试会真的启动应用,把它存在的那个理由从第一屏走到用户要的结果。数到零,你的绿灯就是关于零件的证词,不是关于产品的。