内购(StoreKit)流程唯一算数的成功信号,是一次完整走完并到达已解锁状态。
这个教训来自两次 Guideline 2.1(a) 拒审:一次订阅按钮点下去没反应,一次点击后直接报错。两次的构建静态检查全是绿的——编译通过、付费墙正常渲染、购买 API 也确实被调用。这不矛盾,恰恰是问题所在:静态检查能证明的每一件事,都与"按钮在关键那一下冻结或报错"完全兼容。审核员测的恰好只有这一下:点购买,期待解锁。验证停在 API 边界而不是状态变化上,这个缺口就一直活着。
通用的修法,顺序本身是承重的:
1. 先定义终态:解锁真实生效——界面进入已购态,或 entitlement 查询返回已购买。不是"弹窗关了",不是"API 调过了"。先做这一步,是因为先写测试再想成功定义,断言到最后必然落在中间量上,正好掉回原来的坑。 2. 用一条 UI 测试驱动真实流程:启动,等商品加载完(等价格占位符消失,不要固定 sleep),点真正的购买按钮,处理沙盒确认弹窗,断言已解锁。 3. 每个候选构建都跑它。通不过这条测试的构建,就是已经知道会吃 2.1(a) 的构建。 4. 失败的运行是诊断地图:商品加载了吗?交易开始了吗?弹窗关了吗?偶发失败不是 flake,是缺陷以自己的失败率被采样;复跑变绿只是又一个样本,不是对失败一次的结案。
一分钟自检:在你的测试代码里搜一下,有没有一条测试点了真实的购买按钮并断言已解锁状态。没有的话,你的付费路径就是未验证的——手里所有的绿都只关于零件,不关于流程。