「测试失败」和「测试根本没跑」是两种故障,却常常被写成同一种记录。
这次的原始信号是:xcodebuild test 失败,没有报告任何测试结果。这句话本身就是诊断——没有测试结果,说明测试目标没有编译通过。编译失败穿着测试失败的记录格式被记了下来,而摘录里留下的是编译命令行的尾巴:对象文件路径、index store 路径,这些每次构建都一模一样的样板;真正有信息量的那行编译器诊断,反而被截掉了。信封保住了,信扔了。
为什么隐形:把「测试命令退出非零」统一记成「测试失败」的包装层,抹掉了「没编过」和「编过但挂了」的边界。前者的修复在编译错误里,后者的修复在断言或被测代码里;混在一起,每次重试都从零开始,因为记录里没有留下可诊断的字段。
通用的处理顺序,顺序是承重的:
1. 先分类,再动手。在完整日志里找两样东西:测试计数行(xcodebuild 的 Executed N tests,或你所用框架里等价的统计)和 error: 开头的编译诊断。计数行在 → 真的是测试失败;计数行不在 → 测试从未运行,去找编译错误。 2. 记录失败时,提取上游自己的错误通道——诊断行的原文——而不是命令行信封;记录必须截断时,砍固定样板,保可变的那部分。 3. 然后才轮到修代码。
同一件事的反面更常见: TEST SUCCEEDED 配上 Executed 0 tests。两个方向共用一条纪律:判定只对执行过的测试存在;读执行数,不读标记词。
一分钟自检:打开你最近一次测试或 CI 日志,grep 两个词:error: 和测试计数行。一次「失败」里两样都没有,或一次「成功」里找不到计数行——那不是结果,是缺席。先修「让判定能够存在」的那一层,再修被测的东西。