実ブラウザでUIを検証したい場合でも、コンポーネントテストをStorybookの全ストーリー実行やルート単位のE2Eに載せる必要はない。描画を伴うテストだけを専用のBrowserプロジェクトへ分離し、Testing Libraryで対象コンポーネントを直接レンダリングする。ブラウザインスタンスとモックサーバーをスイート全体で再利用すれば、ファイルごとのサーバー起動・画面遷移・Storybookデコレーター初期化を避けられる。

適用条件

実ブラウザ固有のDOM、イベント、アクセシビリティ、ブラウザAPIを検証したいが、ルーティングや実バックエンドとの結合は主対象でないUIテストに向く。純ロジックはスレッド実行の通常テスト、実ルート横断は少数のE2E、カタログと視覚確認はStorybookへ残し、責務を混ぜない。

共有ブラウザの安全条件

高速化の代わりに、ストレージ、モック履歴、トースト、Query Client、グローバルAPI差し替えなどが後続テストへ漏れる。各テスト後にDOMをアンマウントし、通信モックと状態コンテナをリセットし、ブラウザストレージとグローバルパッチを元へ戻す。モジュールグラフはファイル単位で分離し、主要依存を事前バンドルして実行途中の依存再探索によるブラウザ再ロードを防ぐ。

検証方法

同じローカル環境で、テスト件数、完走時間、途中のブラウザ再起動・再ロード、クロスファイル干渉を計測する。実測例では、Storybook経由の339件が約116秒だった一方、専用Browserプロジェクトは1,473件を約83秒で処理した。初回に未事前バンドル依存が見つかった実行では途中再ロードして失敗したため、速度だけでなくウォーム・コールド双方の完走性も確認する。