1. 基本原則

テストは「実装」ではなく、「振る舞い」を検証する

OK: 「この入力を与えたら、この結果になる」
NG: 「この関数の中でこの関数が呼ばれている」

実装詳細はリファクタで変わりますが、振る舞いは仕様です。

2. 優先順位（何から書くべきか）

　ビジネスロジック　最重要！
壊れると業務に直結する箇所。

(例）
- 金額計算
- 集計ロジック
- フラグによる分岐
条件分岐・境界値
バグが入りやすい箇所。

(チェックすべき例)
- null / undefined
- 0 / 1
- 空配列 / 1件 / 複数件
- 締日またぎ、月跨ぎ
API・Fetcher の振る舞い
外部依存はモックして結果のみ検証。
React コンポーネント（最小限）
UI は「見た目」ではなくユーザー操作に対する結果を見る。

(チェックすべき例)

3. Jest で「書かなくていい」テスト

実務ではここを削るのが重要。

❌ getter / setter
❌ 単純な型変換だけの関数
❌ MUI / React Hook Form の内部挙動
❌ 「実装と同じロジックをテストで再現」

4. describe / test の書き方の型

describe：前提条件
test：期待結果

describe("締日が月末の場合", () => {
  test("2月でも正しく月末日を返す", () => {
    expect(getClosingDate("2025-02")).toBe("2025-02-28");
  });
});

5. testを書く際に問題を切り出す。

const handleSearch = async (formData) => {
  if (loading) return;
  setRows([]);
  setForm(formData);
  setLoading(true);
  try {
    const result = await fetchData(...);

    const normalized = result.map((r) => ({
      ...structuredClone(r),
      isEdited: false,
    }));
  } catch {
    setRows([]);
  } finally {
    setLoading(false);
  }
};

上記コードは、Reactの State 更新と、use-case が混ざっているので分離する。

export const normalizeRows = (
  rows: Rows[]
): Rows[] => {
  return rows.map((r) => ({
    ...structuredClone(r),
    isEdited: false,
  }));
};

export const searchData = async (
  formData: FormData
) => {
  const result = await fetchData({
    formData,
    maxConcurrency: 5,
  });

  const normalized = normalizeRows(result);

  return {
    rows: normalized,
    initialRows: normalized.map((r) => structuredClone(r)),
  };
};

純粋関数を切り出した後のReact側。
React側は結果を受け取るだけ。

const handleSearch = async (formData) => {
  if (loading) return;

  setLoading(true);
  setForm(formData);
  setRows([]);

  try {
    const { rows, initialRows } =
      await searchData(formData);

    setRows(rows);
    setInitialRows(initialRows);
  } catch (e) {
    console.error("検索エラー:", e);
    setRows([]);
  } finally {
    setLoading(false);
  }
};

Reactがないと動かないものは、Jest で無理に単体テストをしなくてもいい。

+ α ユースケース（use-case) とは

use-case とはユーザー操作単位の業務処理です。

use-case は「1ユーザー操作 = 1関数」が基本

検索 → searchXXX
保存 → saveXXX
クリア → clearXXX（不要なことも多い）
登録 → createXXX
更新 → updateXXX

あるボタンを押したら、

どの API を呼ぶか
失敗したらどう扱うか
結果をどう加工するか

業務として正しい形にする、「アプリの判断、流れ」が１つの use-case の塊。

👉 なぜ use-caseを切り出すのか？
理由① Jest でテストしやすい

React 不要 (React と API の間に置く)
入力 → 出力が明確
API はモックできる

理由② 仕様が見える

6. まとめ

Jestでテストを書く時のポイント

💡 Jestの単体テストは、業務ロジックが対象
　● 判断（if / switch）
　● 計算（金額・日付）
　● 整形（map / filter / diff）

💡 React（UI）と業務ロジックは切り離す
💡 業務ロジックは「1ユーザー操作 = 1 use-case」で分離する

💡💡💡
テストは「実装を守る」ものではなく、「仕様を守る」ために書く