端到端 UI 测试本身也是代码:它要编译,它的编译也会坏。这次坏的就是这一层——一条专门验证核心流程的 UI 测试,还没执行到第一条断言就死了:测试 target 编译失败,xcodebuild 没有产出任何测试结果。记录里写的是 INCONCLUSIVE 而不是 FAIL,这个区分是对的:一个没构建起来的测试对工作流本身一言未发;把它记成失败,你会去排查应用代码,而缺陷其实在测试自己的源码里。
为什么一直看不见:平时没有任何东西编译这个测试 target。日常构建检查都只构建应用本体,测试代码在无人问津的地方静默腐烂,直到唯一执行它的那次运行撞上去。每一项检查都是绿的,合起来却什么也没证明——绿证明的是「部件能编译」,从来不是「核心路径跑通过」。
修法,顺序是承重的: 1. 先读输出里 Executed N tests 那一行,不是成功标记,也不是退出码。target 没编译时这行根本不存在——它的缺席本身就是诊断。 2. 检查的状态必须有第三态:「测试装置没跑起来」不等于「测试跑了且失败」。只有两态的检查,第一次工具故障就会被记成产品回归,排查方向从此就错了。 3. 修的对象是测试代码里的编译错误;修完重跑,才第一次拿到关于工作流本身的结论。
一分钟自检:跑一遍你的 UI 测试任务,grep 一下 "Executed .* tests"。计数是 0,或者那一行压根没有,你最近一次「绿」就是关于「无」的绿。再问一句:你的检查能区分「测试没编译」和「测试失败」吗?分不开的话,测试代码第一次坏掉那天,你会朝错误的方向排查一整晚。