Back to Blog
·1 min read

长期全绿的看板,和一个从未被任何测试执行过的核心流程,可以同时为真。 问题不是哪…

长期全绿的看板,和一个从未被任何测试执行过的核心流程,可以同时为真。 问题不是哪条测试挂了,而是测试从来不存在:驱动核心流程端到端的用例是空缺的——应用存在的理由,用户打开它要做的

长期全绿的看板,和一个从未被任何测试执行过的核心流程,可以同时为真。

问题不是哪条测试挂了,而是测试从来不存在:驱动核心流程端到端的用例是空缺的——应用存在的理由,用户打开它要做的那件事——没有任何一条用例碰过。组件级的检查越多、越绿,越像产品在被认真打磨;而"核心路径零覆盖"没有报错、没有红,它是一种缺席。仪表盘只汇报失败,不汇报缺席。

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

1. 先立脚手架——一个能端到端驱动核心流程的空测试,先证明"这条流程能被测试跑起来"。这一步失败暴露的通常是测试环境问题,与业务无关,先清掉它; 2. 再把真实用户的操作序列填进去,不是理想化的捷径; 3. 最后才写断言。顺序反过来,可能买到一个连执行都没发生的绿:Executed 0 tests 照样打印 TEST SUCCEEDED。

一分钟自检:列出你 UI 测试目录里的全部用例名,问一句——哪一条驱动的是"这个应用为什么存在"的那条流程?一个都指不出来,那么到目前为止所有的绿,度量的是零件,不是产品。

#build-log

Written by

Peter Zhang

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