单测记录写着 failed,错误信息却是"这台机器上没有可用的 iOS 模拟器 runtime"。代码一行都没被评判,记录的形状却和真正的测试失败一模一样。
这类事为什么隐形:失败状态把两件事合并了——"跑过了、判定有问题"和"根本没跑起来"。红灯统计把后者也算进失败率,环境缺口(比如一次工具链升级把 runtime 带走)就在数据里伪装成代码质量下降。镜像方向同样成立:TEST SUCCEEDED 配上 Executed 0 tests,是对"空"下的判决。环境坏了给你红,环境看似正常但什么都没执行给你绿——两个方向都在撒谎。
处理顺序,顺序本身是承重的:
1. 先归因,再谈代码。读错误的"主语":点名的是运行环境(runtime 不存在、模拟器起不来、被重启打断、超时且无输出),还是代码?主语是机器的错误对 diff 零信息量,拿它去调试代码是在错误的层面花钱。 2. 先恢复"能出判决"的能力,再花重跑。装回并验证 runtime,然后在同一台机器上跑一个已知能过的最小探针工程做对照:探针过、正式套件挂,问题在套件或代码;探针也挂,问题在环境,你的改动根本还没被看过。 3. 把"没跑起来"单独归类。准入失败(从未开始)和执行失败(跑过且挂了)是两类;混在一起时,一串相同的环境错误看起来像连续回归,把真实信号埋掉。 4. 判决真正产生之后,失败才值得当代码的反馈用。
一分钟自检:翻最近二十条失败记录,数一数错误的主语是机器还是代码;再抽几条绿灯,确认 Executed 的用例数大于零。两个数字都干净,你的红绿板量的才是代码,而不是这台机器的可用性。