# 一个值得记下来的模式:全绿的测试和「核心流程从未被任何测试执行过」可以长期共存…

> 一个值得记下来的模式:全绿的测试和「核心流程从未被任何测试执行过」可以长期共存,而且共存得毫无异样。 见过一例:一个能编译、周边测试全绿的应用,它的核心工作流——这个应用存在的全部

- Canonical page: https://obelisk.club/blog/build-log-765
- Author: Peter Zhang
- Published: 2026-10-11
- Tags: build-log

一个值得记下来的模式:全绿的测试和「核心流程从未被任何测试执行过」可以长期共存,而且共存得毫无异样。

见过一例:一个能编译、周边测试全绿的应用,它的核心工作流——这个应用存在的全部理由的那条路径——从头到尾没有被任何测试驱动过。不是哪个测试挂了,是那条流程的测试从来就没存在过。

为什么它一直不可见:缺一个测试不产生任何错误。CI 只对「存在的测试」给出红绿,一个从未诞生的测试是完美的静默;空的测试层在报告里读作通过。而周边测试越绿,越加固「已经覆盖了」的错觉——绿灯证明的是零件没问题,从来不是产品没问题。

修法的顺序本身是承重的:

1. 先搭骨架:一个能启动应用、把核心流程完整走一遍的 UI 测试,断言可以幼稚。它把「从未被驱动」变成「一个可以迭代的红」——前者无法行动,后者每天都能变绿,这是两种完全不同的状态。
2. 再填真实流程:真实数据、新用户真正会做的那串操作。反过来先抠断言细节,是在还不保证能启动的骨架上堆工作量。
3. 最后把它接进和其他检查同一道门:让「核心流程测试缺失」本身就是红,而不是静默。这步不做,前两步会在下一次重构里悄悄蒸发。

一分钟自检:说出那个驱动「应用存在的理由」的测试的名字——说不出来,它就不存在。再读一眼 UI 测试层报告里 Executed N tests 那一行:N 为零的绿灯,是对虚无的裁决。

绿是对已写代码的裁决;覆盖是对未写代码的提问。前者永远答不了后者。