React Testing Library導入・Jestとの違いとは？書き方【入門】

モダンWeb開発2026.04.212026.04.21

執筆者編集部

Ulty 編集部

監修者Ulty 代表/編集長

大野浩史

この記事のポイント

React Testing Libraryはユーザー視点でDOMを検証し、実装の詳細に依存しない保守性の高いテストを実現するツールであり、導入手順からgetByRole等のクエリ活用、イベント発火、APIモック化など実務的なベストプラクティスが確立されています。

React Testing Library導入・Jestとの違いとは？書き方【入門】

React Testing Libraryの基本的な書き方や設定方法を学び、実装の詳細に依存しない壊れにくいテストのベストプラクティスを身につけたいと考えてはいませんか。

こうした疑問に答えます。

本記事の内容

React Testing Libraryの導入と初期設定
クエリやイベント発火を駆使した基本コードの書き方
実務で役立つ非同期処理やモックの活用手法

2026年のフロントエンド開発において、React Testing Libraryを用いたアクセシビリティ中心のテスト実装は、品質担保に欠かせない要素です。React Testing LibraryとJestの違いを理解し、TypeScript環境やViteでのプロジェクトに導入する際も、npmでのセットアップからスムーズに進めることができます。

本記事を読めば、子要素の取得方法やact関数の使い方など、保守性の高いテスト戦略が理解でき、自信を持ってコードをリリースできるようになるはず。公式のGitHubも参考にしつつ、まずは基本のセットアップから確認していきましょう。

React Testing Libraryとは

React Testing Library（RTL）は、Reactコンポーネントのテストを効率化するために設計された、現代のフロントエンド開発における標準的なテスティングライブラリです。2026年現在、Reactのエコシステムにおいて壊れにくいテストを実現するための必須ツールとして広く普及しています。

RTLは従来のライブラリのようにStateやPropsの内部構造をテストするのではなく、実際のユーザーがブラウザ上で目にするDOMを操作・検証することに特化しています。React Testing Library導入により、ユーザーの視点に立った信頼性の高い品質保証が可能です。

ユーザー目線の設計思想

Reactとは、テストがソフトウェアの使用方法に似ているほど信頼できるという設計思想を支えるUIライブラリで、React Testing Libraryもその思想を根底に共有しています。

従来のテスト手法は内部メソッドの呼び出しを検証していましたが、これではリファクタリングのたびにテストが壊れてしまいます。RTLは以下のポイントを重視し、実装の詳細に依存しないテストを実現しています。

アクセシビリティに基づいたクエリ：getByRoleなど、支援技術を利用するユーザーが見つける方法で要素を特定
実装の詳細を無視：コンポーネントの内部構造ではなく、出力される結果に焦点を当てる

見た目や挙動が変わらない限り、コードを書き換えてもテストが失敗しない保守性の高いコードを記述できます。2026年のトレンドでは、VitestやPlaywrightを活用した実ブラウザ環境でのテスト実行も推奨されています。

フロントエンド開発での役割

フロントエンド開発において、React Testing LibraryはUIの品質を保証するための中心的な役割を担います。

具体的にはコンポーネントのレンダリングや要素の検索、クリックや入力といったユーザーイベントのシミュレーションをサポートしています。TypeScript環境との相性も非常に良く、型安全なテスト実装を容易にします。

導入手順は、プロジェクトのパッケージマネージャーに合わせて以下のコマンドを実行します。

npmを使用する場合： npm install --save-dev @testing-library/react @testing-library/jest-dom @testing-library/user-event
Vite環境で利用する場合： vite.config.tsにtestブロックを追加し、高速なフィードバックサイクルを構築する

2026年の開発現場では、小規模なユニットテストから複雑なインテグレーションテストまで幅広く活用されています。公式GitHubリポジトリでも多くのサンプルが公開されており、初心者でも学習しやすい環境が整っています。

Jestとの関係性

React Testing Libraryを導入する際、JestとRTLそれぞれの役割を正しく理解することが重要です。

RTLはコンポーネントを操作するためのツールであり、JestやVitestはテストを実行し結果を判定するフレームワークです。両者の役割は以下のように明確に分かれています。

項目	React Testing Library	Jest / Vitest
分類	テスティングユーティリティ	テストランナー / フレームワーク
主な役割	DOMのレンダリング・要素取得・イベント発火	テストケースの定義・値の比較・モック作成
依存性	Reactに依存	React以外でも使用可能

かつてはJestとの組み合わせが一般的でしたが、2026年現在はViteベースのプロジェクトが増え、Vitestと組み合わせて使用するスタイルが主流です。フレームワークが変わってもRTLの使い方は共通しているため、一度習得すれば多様な環境で高品質なテストを書けます。

React Testing Libraryの導入手順

Reactアプリケーションの品質を向上させるには、信頼性の高い自動テストが欠かせません。React Testing Libraryは、コードの内部構造ではなくユーザーから見た振る舞いに焦点を当てたライブラリです。

2026年現在のモダンな開発環境において、React Testing Libraryを正しく導入し、保守性の高いテストを書くためのステップを解説します。

① npmでパッケージをインストールする

まずは必要なパッケージをnpm経由でインストールします。テストランナーであるJestやDOM検証用のjest-domを組み合わせるのが、React入門の段階を終えた直後のチームでも理解しやすい標準的な構成です。

以下のコマンドをターミナルで実行してください。

npm install --save-dev @testing-library/react @testing-library/jest-dom @testing-library/user-event jest jest-environment-jsdom

インストールする主要なパッケージの役割をまとめました。

パッケージ名	役割・解説
@testing-library/react	コンポーネントをレンダリングし、DOM操作を行うコアライブラリ。
@testing-library/jest-dom	要素の表示状態などを検証するカスタムマッチャーを提供。
@testing-library/user-event	クリックや入力など、実際のブラウザ操作に近い挙動をシミュレート。
jest / jest-environment-jsdom	テストを実行するエンジンと、Node.js上でブラウザ環境を再現するツール。

2026年の現場では、これらを開発用依存関係として管理することが重要です。

② Vite環境の初期設定を行う

ViteとReactの組み合わせでReact Testing Libraryを利用する場合、JestがViteの構文を解釈するための設定が必要です。

まず、以下のコマンドでJestの初期設定ファイルを作成します。

npx ts-jest config:init

次に、プロジェクトのルートにあるjest.config.jsを編集してsetupTests.tsの読み込み設定を追加しましょう。

setupFilesAfterEnvに '<rootDir>/src/setupTests.ts' を指定
testEnvironmentに 'jsdom' を指定

続いて、src/setupTests.ts ファイルを作成し、以下のコードを記述してください。

import '@testing-library/jest-dom';

最後にpackage.json内のscriptsセクションへ、テスト実行用のコマンドを追記します。

"scripts": {
  "test": "jest"
}

これで、npm testコマンドによりテストを実行できる環境が整います。

③ TypeScriptを使う準備をする

TypeScript環境でReact Testing Libraryを安全に使用するには、型定義とコンパイラの設定が必要です。

まずは型定義ファイルとJestでTypeScriptを扱うためのプリセッタを導入します。

npm install --save-dev @types/jest ts-jest

次にjest.config.jsを修正し、TypeScriptファイルをサポートするように設定します。presetに'ts-jest'を指定し、moduleFileExtensionsにtsやtsxを含めてください。

TypeScriptを導入するメリットは以下の通りです。

getByRoleなどのクエリに型が付き、補完機能が向上する
コンポーネントのPropsに対する型チェックがテスト上でも機能する
リファクタリング時の修正漏れをコンパイルエラーで検知できる

また、tsconfig.jsonのtypesに"jest"を追加することで、テスト内のglobalな関数を正しく認識できます。

④ テストコマンドの動作を確認する

設定が完了したら、簡単なテストを実行して動作を確認します。公式GitHubのサンプルを参考に、最新の書き方を試しましょう。

srcディレクトリ内に App.test.tsx を作成し、userEventを使用して記述します。

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import App from './App';

test('初期表示でタイトルが正しくレンダリングされること', async () => {
  const user = userEvent.setup();
  render(<App />);
  
  const titleElement = screen.getByText(/hello world/i);
  expect(titleElement).toBeInTheDocument();
});

コードが書けたら、以下の手順で動作を検証してください。

ターミナルで npm test を実行する
PASSの表示を確認する
検証内容をわざと書き換えてテストが失敗することを確認する

小さなテストを動かすことで、環境構築の不備を早期に発見できます。正常な動作を確認できたら、子要素の取得や非同期通信のモック化へ進みましょう。

React Testing Libraryの基本的な書き方

React Testing Library（RTL）は、Reactコンポーネントをユーザーの視点でテストするためのライブラリです。従来のテストがコンポーネントの内部状態を検証していたのに対し、RTLはユーザーが目にする画面要素の検証に重点を置きます。

内部のコードをリファクタリングしてもテストが壊れにくいため、高い保守性を実現できるのが特徴です。テストの基本は、render関数でコンポーネントを描画し、screenオブジェクトで要素を取得し、expectを用いて期待する状態を検証する、という3ステップで構成されます。

画面に描画された要素の取得

コンポーネントの描画後は、まずテスト対象の要素を特定する必要があります。RTLはユーザーが画面を認識する際と同じ方法で、アクセシビリティを考慮した要素検索を推奨しています。

要素を取得するクエリには優先順位があり、以下の順番で使用することが望ましいです。

getByRole：ボタンや見出しなどの役割で取得し、nameオプションを併用して正確に指定する
getByLabelText：フォームの入力項目をラベルのテキストで特定する
getByPlaceholderText：入力フォームのプレースホルダーで取得する
getByText：画面上のテキストそのもので取得する
getByTestId：他の方法で取得できない場合に限り、data-testid属性を使用する

例えばボタンを取得する場合、screen.getByRole('button', { name: '送信' }) と記述します。これにより、送信ボタンが支援技術から正しく認識可能かも同時に検証可能です。

ユーザー操作を再現するイベント発火

要素の取得後は、クリックや入力などのユーザー操作をシミュレーションします。2026年現在、イベント発火にはReact Hook Formを使ったフォームの検証でも標準となるuser-eventライブラリを使用するのがベストプラクティスです。

以前はfireEventが使われていましたが、user-eventはブラウザの挙動をより忠実に再現します。フォーカスの移動などを伴うため、テストの信頼性が非常に高い手法です。

基本的な使い方は、まずsetupメソッドでユーザーインスタンスを作成します。次に要素を取得し、clickなどの操作をawaitで待機してください。

const user = userEvent.setup();
const button = screen.getByRole('button', { name: '保存' });
await user.click(button);

ユーザー操作は非同期的に行われるため、必ずasync/awaitを使用して処理を待ちます。user-eventが内部でactを適切に処理するため、開発者が直接意識する必要はありません。

非同期処理を含むコンポーネントの検証

APIからのデータ取得など、ReactのHooksで実装した非同期処理を含む要素をテストする場合はfindBy系のクエリを使います。getBy系は要素がないと即座にエラーになりますが、findBy系は要素が現れるまで最大1,000ms待機します。

非同期処理のテストにおける各クエリの使い分けは、以下の通りです。

クエリの種類	要素がない場合の挙動	主な用途
getBy...	エラーを投げる	描画直後に存在する要素の検証
queryBy...	nullを返す	要素が存在しないことの検証
findBy...	Promiseを返し、待機する	非同期で表示される要素の検証

Vite環境においても、これらのクエリを活用して非同期テストを安定させられます。RTLのクエリは内部でactをラップしているため、開発者が直接呼び出すケースは限定的です。

外部APIを想定したモックの活用

フロントエンドのテストを安定させるには、外部APIへのリクエストをモック化することが不可欠です。ネットワークの状態に左右されず、一貫したテスト結果を得ることが可能になります。

2026年現在も、APIモックにはMock Service Worker（MSW）を使用する方法が推奨されています。MSWはネットワークレベルで通信を傍受するため、実際のブラウザ実行に近い形でテストできます。

APIをモック化する手順は次の通りです。まずレスポンスを定義するハンドラーを作成し、テスト実行前にサーバーを起動します。テスト終了ごとにハンドラーをリセットして干渉を防ぐことが重要です。

APIから取得したデータを確認する際は、findByRoleなどを使用してデータの到着を待機します。公式ドキュメントや公式GitHubリポジトリを参考に、常に最新のモック手法を取り入れてください。

特定の子要素の検証

複雑なUIから特定の領域内にある要素だけを検証したい場合は、within関数を使用します。複数のリストから特定の1行にあるボタンを探す場面などで特に有効です。

手順はまずscreen.getByで親要素を取得し、その範囲内でさらに検索をかけます。

親要素となるコンテナを取得する
within(親要素).getByを用いて、範囲内の子要素を特定する

const listRow = screen.getByTestId('user-row-1');
const deleteButton = within(listRow).getByRole('button', { name: '削除' });
expect(deleteButton).toBeInTheDocument();

このようにスコープを絞り込むことで、同名の要素との競合を避けることができます。TypeScriptと組み合わせて型安全に記述することで、より堅牢なテストコードを作成できます。

React Testing Libraryの実務向けベストプラクティス

React Testing Libraryは、Reactコンポーネントにおけるテストのデファクトスタンダードです。実装の詳細ではなく、ユーザーが目にする情報や操作に焦点を当てたテストを推奨しています。

2026年現在のフロントエンド開発では、高速なVitestがJestに代わり採用されるケースが増えました。しかし、React Testing Libraryの役割や理念は変わりません。実務で品質の高いテストを運用するには、ライブラリの設計思想を深く理解し、ユーザー視点を常に意識することが不可欠です。