## ローカルホストテストの罠開発環境は嘘をつく。ギガビットファイバーのローカルマシンでビルドすると、ネットワークリクエストは**5ms**で完了し、インターフェースは瞬時に反応する。「送信」ボタンを押すと、モーダルが閉じて機能がリリースされる。問題は解決したと思いきや。✅一方、地下鉄の4G回線を使うユーザーは同じボタンを押すと、APIコールに**2秒**かかる。あなたのアプリはそれに対応できていない。ローカルホストと実世界の間のギャップは小さな不便ではなく、重大な障害が隠れている場所だ。**レイテンシの下で壊れるもの：**- 🖱️ **重複送信**：何も起きなかったように見えて、ユーザーが二度クリックし、カードを二重に請求してしまう- 🔄 **フリーズ状態**：パケットが落ちたときにローディングインジケーターが固まる- 🏎️ **レース条件**：レスポンスが順不同で到着し、ユーザー入力が破損するあなたのアプリは、偽の現実でテストしてきたため、弾丸のように堅牢に見える。## なぜsleep()では不十分なのか多くのテストスイートは、次のように遅延をシミュレートしようとする：
ネットワークスロットリングテストの結果があなたのアプリの隠れたバグを暴露する理由
ローカルホストテストの罠
開発環境は嘘をつく。ギガビットファイバーのローカルマシンでビルドすると、ネットワークリクエストは5msで完了し、インターフェースは瞬時に反応する。「送信」ボタンを押すと、モーダルが閉じて機能がリリースされる。問題は解決したと思いきや。✅
一方、地下鉄の4G回線を使うユーザーは同じボタンを押すと、APIコールに2秒かかる。あなたのアプリはそれに対応できていない。
ローカルホストと実世界の間のギャップは小さな不便ではなく、重大な障害が隠れている場所だ。
レイテンシの下で壊れるもの：
あなたのアプリは、偽の現実でテストしてきたため、弾丸のように堅牢に見える。
なぜsleep()では不十分なのか
多くのテストスイートは、次のように遅延をシミュレートしようとする：