React レンダー回数の隔離テスト

定義

「一箇所だけ修正したのに画面全体が描き直される」という React の性能問題を、目ではなく 自動テストで監視 したいときに使う技法だ。特定のコンポーネントが何回描き直されたかを数字で数え、編集後も無関係な部分が0回だけ描かれたかを検査する。

用語を解くと：再レンダー（re-render） は React がコンポーネント関数を再実行して画面を更新すること、隔離（isolation） はある部分を変えても兄弟・祖先コンポーネントが不要に描き直されない状態を言う。jest.mock はテストで特定のモジュールを偽版に差し替える Jest 機能、baseline スナップショットは「正常なときの基準値」を前もって撮っておいたものだ。

正確に言えば React レンダー回数の隔離テスト は、この再レンダー隔離を 単体テストとして契約化（コードが守るべき約束として固定） する方法だ。対象コンポーネントを jest.mock で包んで id ごとのレンダー回数を外部の Map に記録し、値を変える 直前 の baseline スナップショットと以後を比較する。フォーカス・マウントのような付随的な再レンダーは、スナップショットを撮る時点を調節して測定から分離する。

文脈の中で理解する

「深いブロックだけ編集したのに、画面の遠くにある兄弟も描き直される」という不満は、目では見えにくい。プロファイラは CI に入れにくく、「遅くなった」という体感だけでは回帰を捕まえられない。この方法は リファクタの前に 「遠い枝は追加レンダー0回」をテストで刻んでおき、memo・read-model・store 分離を入れた後に 同じテストが GREEN かどうかで改善を数字で証明する。

なぜ必要か

React.memo、selector、external store の最適化はリファクタ一回で崩れやすい。プロファイラは CI に入れにくく、E2E は遅く flake しやすい。「深いノードだけ修正したとき遠い兄弟 subtree は0回追加レンダー」のような 構造的不変 をテストで固定すれば、O(depth)→O(1) のような回帰を素早く捕まえる。

動作原理

1. ギャップ分析：既存テストが flat vs nested、隔離 vs depth だけ、などどの軸をカバーしているかを表にする。共通集合（例：再帰+値変更の隔離） だけを新たに追加する。
2. Mock プローブ：jest.mock('./RowChrome', () => ({ RowChrome: (props) => { counts.set(props.id, (counts.get(props.id) ?? 0) + 1); return ActualRowChrome(props); } })) — 原本は実行、カウントだけ増やす。
3. import 順序：mock はホイスティングされるので、テスト対象の import は mock の 下 に（eslint-disable import/first パターン）。
4. シナリオ：ツリーをレンダー → （必要時）focus で editor をスワップ → baseline スナップショット → 決定的な値変更を1回（Enter split など）→ far branch expect(count).toBe(baseline)。
5. 回帰：アーキテクチャ改善の後、同じテストで祖先も baseline 維持（O(1) の証明）を要求できる。

const renderCounts = new Map<string, number>();

jest.mock("./BlockChrome", () => {
  const Actual = jest.requireActual("./BlockChrome").BlockChrome;
  return {
    BlockChrome: (props: { id: string }) => {
      renderCounts.set(props.id, (renderCounts.get(props.id) ?? 0) + 1);
      return <Actual {...props} />;
    },
  };
});

// import SUT after mock
import { Editor } from "./Editor";

it("does not re-render far siblings on deep edit", () => {
  render(<Editor initialDoc={nestedFiveDeep} />);
  focusDeepestBlock();
  const before = snapshotCounts(renderCounts, ["section-b", "tail"]);

  userEvent.keyboard("{Enter}"); // deterministic value change

  const after = snapshotCounts(renderCounts, ["section-b", "tail"]);
  expect(after).toEqual(before);
});

実務での適用

• ツリー・リスト・テーブルの行単位の memo・store 購読を設計する前後で、far branch が0増加であることを assert する。
• typing シミュレーションより キーボードアクション一回（split、toggle）の方が jsdom で決定的だ。
• Provider を mock して コンテナ render === 0 を測定するときは、コンテナと1:1でレンダーされる下位（Provider）をプローブする。
• テスト名に「隔離」「O(1)」の意図を明示して、後でスキップされないようにする。

トレードオフ

• mock は実装の細部に結合する — プローブ対象コンポーネントの名前が変わればテストも修正。
• グローバルな Map はテスト間で beforeEach 初期化が必要。
• 「0追加レンダー」は そのシナリオ にだけ該当 — 別の interaction 経路は別途テスト。
• React Strict Mode の double-render は setup で一度織り込むか、プローブ設計を調整する。

使ってはいけない場合

• スナップショットの全 DOM 比較だけで性能契約を代替しようとするとき — 意図が不明確だ。
• プローブが多すぎて、すべてのラッパーを mock するとテストが実装のミラーになるとき。

よくある間違い

• baseline を focus の 前 に撮り、static→editor のスワップを値変更と誤認する。
• mock が原本を呼ばず、動作は壊れているのにカウントだけ通過する。
• flat な3兄弟テストだけがあり、深さ+値変更 の軸を空けたまま。
• userEvent.type の長文入力を flake なく隔離テストに使う。

関連概念

• react-context-render-granularity — context・memo が壊れる文脈
• normalized-render-entry-projection — 隔離を作る read-model パターン
• jest-esm-vendor-shim — Jest 環境での mock・import の問題