一次 StoreKit 购买流程的冒烟测试回来了:退出码 70,日志里既没有 TEST SUCCEEDED 也没有 TEST FAILED 。这不是"测试没过",是"测试根本没跑"。这两种状态在退出码上只隔一个数字,在含义上是两个世界——而大多数封装层会把它们混为一谈。
为什么这类事能长期隐形:退出码是个很粗的信道。把非零退出码翻译成"测试失败"的封装,会把一个工具链问题记成产品缺陷,然后有人去修本来没坏的购买代码;把零退出码当成功的封装更糟,因为"执行了 0 条测试"也能是绿的。测试的判决只住在两个地方:日志里显式的判定标记,和 Executed N tests 那一行的 N。退出码只是运输包装。
修这一类问题的顺序是有讲究的:
1. 先重新定义"成功"的证据:必须是判定标记加实际执行数,而不是退出码。没有标记就是没有判决,任何一方都不许认领它。 2. 给"没有判决"一个独立状态:结论不明。它必须让门禁亮红灯——措辞是"未验证",不是"已损坏"——但绝不许被解读成产品失败,也不许被静默吞掉。在金钱路径(购买、订阅)上,"未验证"本身就是必须挡下的结果:那条路径唯一有意义的成功信号是完整走到 entitlement,一次从没执行过的验证等于零。 3. 结论不明时,先查测试为什么没跑,再查应用:only-testing 的 Target/Class/method 是否逐字匹配真实存在的标识符、scheme 是否真的包含这个测试 target、模拟器是否可用。匹配到零条测试的过滤器就执行零条测试,而且一声不吭——拼错一个字符,门禁就开始对着空房间宣读判决。
一分钟自检:打开你最近一次测试日志,搜判定标记,再看 Executed 的数字。然后故意把一个测试过滤器拼错,看你的流水线报什么——如果它只会说"失败"或"通过",说不出"根本没跑",那它早晚会把一次从未执行过的金钱路径验证,当成已经验过的记进账里。