# 一次失败的测试运行,没有点名任何一条用例。 日志的形状是这样的:xcodebui…

> 一次失败的测试运行,没有点名任何一条用例。 日志的形状是这样的:xcodebuild 的汇总行说 TEST FAILED,报了 24 条用例,可翻遍输出找不到一行 "Test Ca

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

一次失败的测试运行,没有点名任何一条用例。

日志的形状是这样的:xcodebuild 的汇总行说 TEST FAILED,报了 24 条用例,可翻遍输出找不到一行 "Test Case … failed"——只有一串 "started",其中几条永远没等到自己的 passed/failed。

这种红为什么能一路伪装成普通的断言失败:汇总行只携带 verdict,不携带证据。如果封装层只记录退出状态,"失败但无人被点名"就会和"断言不通过"写成同一种记录,而两者的病因完全不同。前者几乎总是测试宿主跑到一半死了——崩溃、挂死、或者与测试守护进程的连接断开。error 字段为空的失败记录不是"干净的失败",是病因在到达日志之前就被某一层吞掉了;要修的第一件事就是找回被吞掉的那句话,而不是继续猜代码哪里错了。

定位的顺序,顺序本身是承重的:

1. 数 started,别读 verdict。用 grep 对比 "Test Case … started" 与 "passed|failed" 的行数,差集里最后一条没有配对结果的 started,就是进程死掉的现场。
2. 单独重跑那一条用例。宿主崩溃会稳定复现;偶尔绿一次只是又采了一个样本,不是闭环。
3. 宿主还活着但就是不出结果,就对它抓几秒采样:transcript 永远不会说出挂在哪儿,采样能说到文件和行号。
4. 修记录层的这一类问题,而不只修这一条:把"退出非零且没有命名失败"记成 unverified——既不算失败也不算通过,强制下一个人去看原始输出。同枚硬币的另一面是 TEST SUCCEEDED 配上 Executed 0 tests:两种情况下都是 verdict 在说话、证据没说话,而证据才是你要读的东西。

一分钟自检:拿你最近一次测试日志,数一遍用例的 begun/finished(各家框架叫法不同,成对存在的标记都有)。数目对不上,你看到的红——或者更糟,你看到的绿——就没有证据支撑。