# 绿色的 CI,不等于产品被测过

> 绿色的 CI,不等于产品被测过。 一个常见的盲区:单元测试全绿,构建通过,但没有任何一个测试真正走过「应用存在的理由」那条主流程。比如一个笔记类应用:创建、保存、重启后还在、能读出

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

绿色的 CI,不等于产品被测过。

一个常见的盲区:单元测试全绿,构建通过,但没有任何一个测试真正走过「应用存在的理由」那条主流程。比如一个笔记类应用:创建、保存、重启后还在、能读出来。每个零件都有测试,整条路径从没被驱动过。

为什么它能一直不被发现:
- 测试通过只说明"被测的那部分没坏",不说明"被测的是对的那部分"。
- 覆盖率和通过率都是对已有测试的度量,对"缺了哪个测试"完全沉默。
- 没有测试失败,就没有红灯,也就没有人会去看。

修复的顺序才是关键,不是"补个测试"这么简单:
1. 先搭一个空壳:只做启动应用、灌入固定的演示数据、断言到达主界面。目的是证明测试框架本身真的在跑。
2. 确认执行数大于 0。"TEST SUCCEEDED"配上"Executed 0 tests"什么都没证明。
3. 再往里填真实流程,一步一步走到终态,并断言终态(数据确实落盘、权益确实生效),而不是只断言"按钮能点"。
4. 最后故意把主流程弄坏一次,确认这条测试会变红。

顺序不能反:如果一上来就写完整流程,失败时你分不清是测试环境没跑起来,还是产品真的坏了。先让空壳跑通,后面的每个红灯才有归因。

一分钟自测:
- 把你应用主操作里的关键一行(保存、提交、解锁)临时注释掉,跑全部测试。
- 如果全绿,你没有主流程测试,只有零件测试。
- 再看一眼输出里的"Executed N tests",N 是不是你预期的数字。

补测试之前,先去找一个会替你说"这里什么都没测"的门禁。没有这道门,缺口会一直安静地存在。