React Testing Libraryで保守性と可読性を向上させるテスト説明文の書き方

公開日：2025年1月22日

React Testing Libraryとは？

React Testing Libraryは、フロントエンド開発においてユーザー視点でのテストを重視するテストライブラリです。

特徴として、DOMや内部状態に依存せず、実際のユーザーの操作に近い形でのテスト実施が可能です。

この記事では、React Testing Libraryにおけるテストの説明文の書き方にフォーカスし、ユーザー視点を意識した設計のポイントや、避けるべきアンチパターンについて解説します。

React Testing Libraryの特徴

ユーザー操作をシミュレート
ボタンのクリックやフォーム入力など、実際の操作を再現するテストが中心です。
内部実装に依存しない
DOMや内部状態に依存するテストではなく、表示や操作結果を検証します。
ユーザー体験を重視
ユーザーが「何を見るか」「何を操作するか」に焦点を当てます。

そのためユーザーの視点に立ち、「何が起きるべきか」をわかりやすく伝えるものにする必要があります。

テストの説明文の付け方

「何をテストするのか」ではなく「何が期待されるのか」を記載するのがベターかと思います。

メリットとしては他者から見ても何のテストを実施しているかわかりやすいという点と、実装内容をリファクタリングした際にいちいちテストケースの説明を変更しなくて良いといった点です。

🙅‍♂️ 悪い例①：ボタンがクリックされたら状態を更新する

test("ボタンがクリックされたら状態を更新する", () => {
  // 内部状態を検証するテスト（ユーザー視点が不足）
  const { getByText } = render(<MyComponent />);
  const button = getByText("Click Me");

  userEvent.click(button);

  expect(myState).toBe(true);
});

🙅‍♂️ 悪い例②：状態がtrueのとき、モーダルコンポーネントをレンダリングする

test("状態がtrueのとき、モーダルコンポーネントをレンダリングする", () => {
  // 状態のみに依存したテスト（内部実装への依存）
  const { container } = render(<MyComponent state={true} />);
  expect(container.querySelector(".modal")).toBeInTheDocument();
});

🙆‍♂️ 良い例①：送信ボタンをクリックすると、確認モーダルが表示される

test("送信ボタンをクリックすると、確認モーダルが表示される", () => {
  // ユーザー視点でのテスト
  const { getByText, queryByText } = render(<MyComponent />);
  const submitButton = getByText("送信");

  userEvent.click(submitButton);

  expect(queryByText("確認しますか？")).toBeInTheDocument();
});

🙆‍♂️ 良い例②：無効なメールアドレスが入力された場合、エラーメッセージを表示する

test("無効なメールアドレスが入力された場合、エラーメッセージを表示する", () => {
  // ユーザーの操作とその結果をテスト
  const { getByLabelText, getByText } = render(<MyComponent />);
  const emailInput = getByLabelText("メールアドレス");
  const submitButton = getByText("送信");

  userEvent.change(emailInput, { target: { value: "invalid-email" } });
  userEvent.click(submitButton);

  expect(getByText("メールアドレスが無効です")).toBeInTheDocument();
});

テストの説明文のアンチパターン

内部実装への依存を示す命名
React Testing Libraryは内部状態をテストすることを目的としていないため、stateやpropsに依存した説明は避ける
抽象的すぎる説明
実装の詳細を説明する

さいごに

React Testing Libraryはユーザー視点でのテストを重視しており、テストケース名の命名もその視点に沿うことが重要です。

内部実装に依存せず、「何をしたらどうなるか」を具体的かつ簡潔に記述することで、保守性や可読性が向上します。