React Testing Library: グローバルチームのためのコンポーネントテストのベストプラクティス

ウェブ開発の世界が絶え間なく進化する中で、Reactアプリケーションの信頼性と品質を確保することは最も重要です。これは、多様なユーザーベースとアクセシビリティ要件を持つプロジェクトに取り組むグローバルチームにとっては特に当てはまります。React Testing Library（RTL）は、コンポーネントテストに対する強力でユーザー中心のアプローチを提供します。実装の詳細に焦点を当てる従来のテスト方法とは異なり、RTLはユーザーがコンポーネントを操作するのと同じようにテストすることを推奨し、より堅牢で保守しやすいテストにつながります。この包括的なガイドでは、グローバルなオーディエンスに適したアプリケーションを構築することに焦点を当てて、ReactプロジェクトでRTLを活用するためのベストプラクティスを詳しく説明します。

React Testing Libraryを選ぶ理由

ベストプラクティスに入る前に、RTLが他のテストライブラリよりも優れている理由を理解することが重要です。主な利点をいくつかご紹介します。

• ユーザー中心のアプローチ: RTLは、ユーザーの視点からコンポーネントをテストすることを優先します。ユーザーと同じ方法（ボタンをクリックしたり、入力フィールドに入力したりするなど）でコンポーネントを操作し、より現実的で信頼性の高いテストエクスペリエンスを保証します。
• アクセシビリティ重視: RTLは、障害を持つユーザーを考慮した方法でコンポーネントをテストすることを推奨することにより、アクセシブルなコンポーネントの作成を促進します。これは、WCAGなどのグローバルなアクセシビリティ標準に沿っています。
• メンテナンスの削減: （内部状態、特定の関数呼び出しなどの）実装の詳細をテストすることを避けることで、コードをリファクタリングするときにRTLテストが壊れる可能性が低くなります。これにより、より保守しやすく、回復力のあるテストが実現します。
• 改善されたコード設計: RTLのユーザー中心のアプローチは、ユーザーがコンポーネントをどのように操作するかを考えることを強制するため、より優れたコンポーネント設計につながることがよくあります。
• コミュニティとエコシステム: RTLは、大規模で活発なコミュニティを誇り、豊富なリソース、サポート、拡張機能を提供します。

テスト環境のセットアップ

RTLを始めるには、テスト環境をセットアップする必要があります。CRA（Create React App）を使用した基本的なセットアップを次に示します。CRAには、JestとRTLがプリコンフィギュアされています。

npx create-react-app my-react-app
cd my-react-app
npm install --save-dev @testing-library/react @testing-library/jest-dom

説明:

• `npx create-react-app my-react-app`: Create React Appを使用して新しいReactプロジェクトを作成します。
• `cd my-react-app`: 新しく作成されたプロジェクトディレクトリに移動します。
• `npm install --save-dev @testing-library/react @testing-library/jest-dom`: 必要なRTLパッケージを開発依存関係としてインストールします。 `@testing-library/react`はRTLのコア機能を提供し、`@testing-library/jest-dom`はDOMを操作するための便利なJestマッチャーを提供します。

CRAを使用していない場合は、JestとRTLを個別にインストールし、RTLを使用するようにJestを構成する必要があります。

React Testing Libraryを使用したコンポーネントテストのベストプラクティス

1. ユーザーインタラクションに似たテストを作成する

RTLの基本原則は、コンポーネントをユーザーと同じようにテストすることです。これは、内部実装の詳細ではなく、ユーザーが見て行うことに焦点を当てることを意味します。RTLが提供する`screen`オブジェクトを使用して、テキスト、ロール、またはアクセシビリティラベルに基づいて要素をクエリします。

例: ボタンクリックのテスト

簡単なボタンコンポーネントがあるとします。

// Button.js
import React from 'react';

function Button({ onClick, children }) {
  return {children};
}

export default Button;

RTLを使用してテストする方法を次に示します。

// Button.test.js
import React from 'react';
import { render, screen, fireEvent } from '@testing-library/react';
import Button from './Button';

describe('Button Component', () => {
  it('calls the onClick handler when clicked', () => {
    const handleClick = jest.fn();
    render(Click Me);

    const buttonElement = screen.getByText('Click Me');
    fireEvent.click(buttonElement);

    expect(handleClick).toHaveBeenCalledTimes(1);
  });
});

説明:

• `render(Click Me)`: モックの`onClick`ハンドラーを使用してButtonコンポーネントをレンダリングします。
• `screen.getByText('Click Me')`: 「Click Me」というテキストを含む要素のドキュメントをクエリします。これは、ユーザーがボタンを識別する方法です。
• `fireEvent.click(buttonElement)`: ボタン要素でクリックイベントをシミュレートします。
• `expect(handleClick).toHaveBeenCalledTimes(1)`: `onClick`ハンドラーが1回呼び出されたことをアサートします。

これが実装の詳細をテストするよりも優れている理由: 別のイベントハンドラーを使用したり、内部状態を変更したりするようにButtonコンポーネントをリファクタリングすることを想像してください。特定のイベントハンドラー関数をテストしていた場合、テストは失敗します。ユーザーインタラクション（ボタンのクリック）に焦点を当てることで、テストはリファクタリング後も有効なままです。

2. ユーザーの意図に基づいてクエリを優先する

RTLは、要素を見つけるためのさまざまなクエリメソッドを提供します。ユーザーがコンポーネントを認識および操作する方法を最もよく反映しているため、次のクエリをこの順序で優先します。

• getByRole: このクエリは最もアクセスしやすく、最初に選択する必要があります。これにより、ARIAロール（ボタン、リンク、見出しなど）に基づいて要素を見つけることができます。
• getByLabelText: これを使用して、入力フィールドなど、特定のラベルに関連付けられた要素を見つけます。
• getByPlaceholderText: これを使用して、プレースホルダーテキストに基づいて入力フィールドを見つけます。
• getByText: これを使用して、テキストコンテンツに基づいて要素を見つけます。具体的で、複数の場所に表示される可能性のある一般的なテキストの使用は避けてください。
• getByDisplayValue: これを使用して、現在の値に基づいて入力フィールドを見つけます。

例: フォーム入力のテスト

// Input.js
import React from 'react';

function Input({ label, placeholder, value, onChange }) {
  return (
    

      {label}
      
    
  );
}

export default Input;

推奨されるクエリの順序を使用してテストする方法を次に示します。

// Input.test.js
import React from 'react';
import { render, screen, fireEvent } from '@testing-library/react';
import Input from './Input';

describe('Input Component', () => {
  it('updates the value when the user types', () => {
    const handleChange = jest.fn();
    render();

    const inputElement = screen.getByLabelText('Name');
    fireEvent.change(inputElement, { target: { value: 'John Doe' } });

    expect(handleChange).toHaveBeenCalledTimes(1);
    expect(handleChange).toHaveBeenCalledWith(expect.objectContaining({ target: { value: 'John Doe' } }));
  });
});

説明:

• `screen.getByLabelText('Name')`: `getByLabelText`を使用して、「Name」というラベルに関連付けられた入力フィールドを見つけます。これは、入力を見つけるための最もアクセスしやすく、ユーザーフレンドリーな方法です。

3. 実装の詳細のテストを避ける

前述のように、内部状態、関数呼び出し、または特定のCSSクラスのテストは避けてください。これらは変更される可能性のある実装の詳細であり、脆いテストにつながる可能性があります。コンポーネントの観察可能な動作に焦点を当てます。

例: 状態を直接テストすることを避ける

特定の状態変数が更新されるかどうかをテストする代わりに、コンポーネントがその状態に基づいて正しい出力をレンダリングするかどうかをテストします。たとえば、コンポーネントがブール状態変数に基づいてメッセージを表示する場合、状態変数自体をテストするのではなく、メッセージが表示または非表示になっているかどうかをテストします。

4. 特定のケースには`data-testid`を使用する

一般的に`data-testid`属性の使用は避けるのが最善ですが、役立つ特定のケースがあります。

• セマンティックな意味を持たない要素: 意味のあるロール、ラベル、またはテキストを持たない要素をターゲットにする必要がある場合は、`data-testid`を使用できます。
• 複雑なコンポーネント構造: 複雑なコンポーネント構造では、`data-testid`を使用すると、脆弱なセレクターに依存せずに特定の要素をターゲットにできます。
• アクセシビリティテスト: `data-testid`は、CypressやPlaywrightなどのツールを使用したアクセシビリティテスト中に特定の要素を識別するために使用できます。

例: `data-testid`の使用

// MyComponent.js
import React from 'react';

function MyComponent() {
  return (
    

      
This is my component.
    
  );
}

export default MyComponent;

// MyComponent.test.js
import React from 'react';
import { render, screen } from '@testing-library/react';
import MyComponent from './MyComponent';

describe('MyComponent', () => {
  it('renders the component container', () => {
    render();
    const containerElement = screen.getByTestId('my-component-container');
    expect(containerElement).toBeInTheDocument();
  });
});

重要: 他のクエリメソッドが適切でない場合にのみ、`data-testid`を控えめに使用してください。

5. 意味のあるテストの説明を作成する

明確で簡潔なテストの説明は、各テストの目的を理解し、障害をデバッグするために重要です。テストが検証している内容を明確に説明する説明的な名前を使用します。

例: 良いテストの説明と悪いテストの説明

悪い例: `it('動作する')`

良い例: `it('正しいあいさつメッセージを表示する')`

さらに良い例: `it('nameプロパティが指定されていない場合、「Hello, World!」というあいさつメッセージを表示する')`

より良い例では、特定の条件下でのコンポーネントの期待される動作を明確に示しています。

6. テストを小さく、焦点を絞る

各テストは、コンポーネントの動作の1つの側面を検証することに焦点を当てる必要があります。複数のシナリオをカバーする大規模で複雑なテストの作成は避けてください。小さく、焦点を絞ったテストは、理解、保守、およびデバッグが容易です。

7. テストダブル（モックとスパイ）を適切に使用する

テストダブルは、テストしているコンポーネントをその依存関係から分離するのに役立ちます。モックとスパイを使用して、外部サービス、API呼び出し、またはその他のコンポーネントをシミュレートします。

例: API呼び出しのモック

// UserList.js
import React, { useState, useEffect } from 'react';

function UserList() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    async function fetchUsers() {
      const response = await fetch('/api/users');
      const data = await response.json();
      setUsers(data);
    }

    fetchUsers();
  }, []);

  return (
    

      {users.map(user => (
        
{user.name}
      ))}
    
  );
}

export default UserList;

// UserList.test.js
import React from 'react';
import { render, screen, waitFor } from '@testing-library/react';
import UserList from './UserList';

global.fetch = jest.fn(() =>
  Promise.resolve({
    json: () => Promise.resolve([
      { id: 1, name: 'John Doe' },
      { id: 2, name: 'Jane Smith' },
    ]),
  })
);

describe('UserList Component', () => {
  it('fetches and displays a list of users', async () => {
    render();

    // Wait for the data to load
    await waitFor(() => screen.getByText('John Doe'));

    expect(screen.getByText('John Doe')).toBeInTheDocument();
    expect(screen.getByText('Jane Smith')).toBeInTheDocument();
  });
});

説明:

• `global.fetch = jest.fn(...)`: `fetch`関数をモックして、事前定義されたユーザーのリストを返します。これにより、実際のAPIエンドポイントに依存せずにコンポーネントをテストできます。
• `await waitFor(() => screen.getByText('John Doe'))`: 「John Doe」というテキストがドキュメントに表示されるのを待ちます。これは、データが非同期的にフェッチされるため、必要です。

8. エッジケースとエラー処理をテストする

ハッピーパスだけをテストしないでください。エッジケース、エラーシナリオ、および境界条件を必ずテストしてください。これは、潜在的な問題を早期に特定し、コンポーネントが予期しない状況を適切に処理することを保証するのに役立ちます。

例: エラー処理のテスト

APIからデータをフェッチし、API呼び出しが失敗した場合にエラーメッセージを表示するコンポーネントを想像してください。API呼び出しが失敗した場合にエラーメッセージが正しく表示されることを検証するためのテストを作成する必要があります。

9. アクセシビリティに焦点を当てる

アクセシビリティは、包括的なウェブアプリケーションを作成するために重要です。RTLを使用してコンポーネントのアクセシビリティをテストし、WCAGなどのアクセシビリティ標準を満たしていることを確認します。主なアクセシビリティの考慮事項をいくつか示します。

• セマンティックHTML: セマンティックHTML要素（``、`
• ARIA属性: 特にカスタムコンポーネントの場合、ARIA属性を使用して、要素のロール、状態、およびプロパティに関する追加情報を提供します。
• キーボードナビゲーション: すべてのインタラクティブな要素がキーボードナビゲーションでアクセスできることを確認します。
• 色のコントラスト: 視覚障害のあるユーザーがテキストを読みやすくするために、十分な色のコントラストを使用します。
• スクリーンリーダーの互換性: スクリーンリーダーでコンポーネントをテストして、視覚障害のあるユーザーに意味のある理解しやすいエクスペリエンスを提供していることを確認します。

例: `getByRole`を使用したアクセシビリティのテスト

// MyAccessibleComponent.js
import React from 'react';

function MyAccessibleComponent() {
  return (
    X
  );
}

export default MyAccessibleComponent;

// MyAccessibleComponent.test.js
import React from 'react';
import { render, screen } from '@testing-library/react';
import MyAccessibleComponent from './MyAccessibleComponent';

describe('MyAccessibleComponent', () => {
  it('renders an accessible button with the correct aria-label', () => {
    render();
    const buttonElement = screen.getByRole('button', { name: 'Close' });
    expect(buttonElement).toBeInTheDocument();
  });
});

説明:

• `screen.getByRole('button', { name: 'Close' })`: `getByRole`を使用して、アクセス可能な名前が「Close」のボタン要素を見つけます。これにより、ボタンがスクリーンリーダー用に適切にラベル付けされていることを確認します。

10. テストを開発ワークフローに統合する

テストは、後回しにするのではなく、開発ワークフローの不可欠な部分である必要があります。コードがコミットまたはデプロイされるたびにテストが自動的に実行されるように、テストをCI/CDパイプラインに統合します。これは、バグを早期にキャッチし、リグレッションを防ぐのに役立ちます。

11. ローカリゼーションと国際化（i18n）を検討する

グローバルアプリケーションの場合、テスト中にローカリゼーションと国際化（i18n）を検討することが重要です。コンポーネントが異なる言語とロケールで正しくレンダリングされることを確認します。

例: ローカリゼーションのテスト

ローカリゼーションに`react-intl`や`i18next`などのライブラリを使用している場合は、テストでローカリゼーションコンテキストをモックして、コンポーネントが正しい翻訳されたテキストを表示していることを確認できます。

12. 再利用可能なセットアップのためのカスタムレンダリング関数を使用する

大規模なプロジェクトに取り組んでいる場合、複数のテストで同じセットアップ手順を繰り返していることに気付くかもしれません。重複を避けるために、共通のセットアップロジックをカプセル化するカスタムレンダリング関数を作成します。

例: カスタムレンダリング関数

// test-utils.js
import React from 'react';
import { render } from '@testing-library/react';
import { ThemeProvider } from 'styled-components';
import theme from './theme';

const AllTheProviders = ({ children }) => {
  return (
    
      {children}
    
  );
}

const customRender = (ui, options) =>
  render(ui, { wrapper: AllTheProviders, ...options })

// re-export everything
export * from '@testing-library/react'

// override render method
export { customRender as render }

// MyComponent.test.js
import React from 'react';
import { render, screen } from './test-utils'; // Import the custom render
import MyComponent from './MyComponent';

describe('MyComponent', () => {
  it('renders correctly with the theme', () => {
    render();
    // Your test logic here
  });
});

この例では、ThemeProviderでコンポーネントをラップするカスタムレンダリング関数を作成します。これにより、すべてのテストでThemeProviderのセットアップを繰り返すことなく、テーマに依存するコンポーネントを簡単にテストできます。

結論

React Testing Libraryは、コンポーネントテストに対する強力でユーザー中心のアプローチを提供します。これらのベストプラクティスに従うことで、ユーザーの行動とアクセシビリティに焦点を当てた、保守しやすく効果的なテストを作成できます。これにより、グローバルなオーディエンス向けの、より堅牢で信頼性が高く、包括的なReactアプリケーションが実現します。ユーザーインタラクションを優先し、実装の詳細のテストを避け、アクセシビリティに焦点を当て、テストを開発ワークフローに統合することを忘れないでください。これらの原則を採用することで、世界中のユーザーのニーズを満たす高品質のReactアプリケーションを構築できます。

主なポイント:

• ユーザーインタラクションに焦点を当てる: ユーザーが操作するのと同じようにコンポーネントをテストします。
• アクセシビリティを優先する: コンポーネントが障害のあるユーザーにとってアクセス可能であることを確認します。
• 実装の詳細を避ける: 内部状態または関数呼び出しをテストしないでください。
• 明確で簡潔なテストを作成する: テストを理解しやすく、保守しやすくします。
• テストをワークフローに統合する: テストを自動化し、定期的に実行します。
• グローバルなオーディエンスを検討する: コンポーネントが異なる言語とロケールで適切に動作することを確認します。