记一条 UI 测试的坑。
xcodebuild 跑核心工作流的 UI 测试,测试 target 没有编译出来,整次运行没有报告任何测试结果——而它在日志里的样子,和"测试真的跑了并且挂了"一模一样:非零退出码,失败状态,一切照常。真正的病因是一个编译错误,躺在构建输出里;没有人在一次"测试失败"里去找编译错误。
为什么它能隐形:退出码只有两种颜色,而"测试没有发生"和"测试发生了但失败"共用其中一种。反面更阴:TEST SUCCEEDED 旁边跟着 Executed 0 tests,绿灯照样亮。一个从不执行的测试和一个执行失败的测试,在记录里没有区别——而核心工作流的 UI 测试恰恰是唯一盯着主路径的那双眼睛,它悄悄闭上时代价最高。
修的顺序才是负载所在:
1. 先问这次运行有没有开口说话:输出里有没有 Executed N tests 这样的结果行。没有,这就是对测试装置的判决,不是对产品代码的判决。 2. 去构建输出里找编译错误,把测试 target 修到能编译。在此之前对产品代码做的一切调试,都是在一段从没被评判过的 diff 上盲打。 3. 装置能说话了,测试结论才开始算数。CI 若把"target 没建出来"和"测试失败"折叠成同一个状态,就是把最该分开的两类信号焊死在一起。
一分钟自检:跑一遍你的 UI 测试,grep 输出里的 Executed。那行缺失、或者数字是 0,这次运行对产品代码的了解就是零——无论面板上显示绿还是红。再顺手确认 CI 会区分"构建失败"和"测试失败";做到这两点,这个坑就再也伪装不成测试结论了。