绿板用沉默说谎。
一个所有检查都绿着的应用,直到有一道检查问了个不一样的问题:"端到端驱动核心流程的那个测试文件在哪?"答案是没有。这个应用存在的理由就是那条流程,而它从未被任何测试真正执行过。
为什么它一直看不见:测试门只会运行存在的东西。缺失的测试不是失败的测试,是"不存在";而不存在产出的是绿色。每个零件各自正确,拼接起来的主干路径却可能一次都没跑过——绿灯统计的是覆盖到的部分,对没覆盖的部分一无所知,也一无所言。组件级全绿和核心流程零覆盖从来不是矛盾,是同一个事实的两面。
通用的修法,顺序本身是承重的:
1. 先用一句话说出核心流程:用户打开这个产品,究竟是为了完成哪件事。这句话说不出来,后面全是白搭。 2. 再搭脚手架,先不写断言:建一个端到端驱动这条路径的 UI 测试骨架,让它真的把流程跑通。骨架跑不通,说明入口本身不支持自动化——这比任何断言都更早地暴露问题。 3. 然后填真实步骤:用户真实会做的那串动作,不是占位符,不是"稍后再补"。 4. 最后把门做成结构性的:检查必须断言"核心流程测试存在",文件缺失即红,而不是目录空了就静默跳过。让缺席本身成为失败。
顺序不能换的原因:先写断言再搭骨架,得到的是测环境不测产品的测试;先加门再填真实流程,门会在占位符上变绿,把假绿固化成"已验证"。
一分钟自查:打开你的 UI 测试目录,只问一个问题——哪个文件端到端驱动了核心流程?答不出文件名,或那个文件根本不存在,你的绿灯对唯一重要的路径就一无所证。更进一步:在 CI 里加一条存在性断言,让"没有这个文件"直接红。绿板不统计缺席,就让这条断言替它统计。