課題: 実ブラウザでの描画テストを高速化するため、全テストファイルを１つのブラウザインスタンス(タブ)で通す構成（モジュールグラフはファイルごとに分離しつつ、ブラウザコンテキスト自体は共有）を取ると、ファイル間で実行がインターリーブし、共有コンテキスト由来の transient なクロスファイル干渉が稀に起きることがある（プロジェクト側も既知の問題として retry: 2 で吸収していた）。ここに、他テストより数倍〜十数倍重い（大量の DOM 要素を作るフィクスチャ、大量の再レンダーを伴う操作等）テストを追加すると、同じ共有コンテキスト内でインターリーブ実行される別ファイルのテスト（CI のような低速・制約の強いランナーでは特に）が、タイミング依存のレースで落ちやすくなる。

検知の難しさ: この種の干渉はローカル(通常より高速・余裕のあるマシン)ではあっさり再現しないことがある。具体的には、重いテストの実行時間自体はローカルでも数百 ms になりうるが、それが別ファイルの内部スケジューリング（rAF/setTimeout 等）を実際に後回しにするかどうかは実行順序・マシン負荷に依存するため、ローカルでは数回実行しても全て green になりうる。

対処: 共有ブラウザ構成のテストプロジェクトにテストを追加する際は、そのファイル内他テストの実行時間と比較し、大幅に上回るものがあれば疑って見る。大量データを扱う検証は、検証したい性質（例: 初期表示範囲を超える件数であること）を満たす最小の件数まで縮める。具体的な改善例として、300×100(3万セル)規模のフィクスチャを小規模に切り詰めることで単体実行時間が数倍〜十数倍縮小し、他テストと同等の重さに溶け込んだ。

構造的シグナル: CI での失敗ログが「一見無関係な別ファイルのテストが落ちる」形を取り、その失敗が特定のデプロイ以降のコミットで毎回発生するのにローカルで1回も再現しない場合、共有ブラウザ構成の既知の transient 干渉クラスを疑う。

適用条件: Vitest の browser mode や Playwright のように、設定で複数テストファイルを 1 つのブラウザインスタンス/コンテキストで共有する構成全般に当てはまる。