react-native-testing
React Native Testing Library(RNTL)v13・v14(`@testing-library/react-native`)を使用したテストの作成・レビュー・修正時に機能するスキルです。`render`・`screen`・各種クエリ(getBy / getAllBy / queryBy / findBy)・Jest マッチャー・`userEvent`・`fireEvent`・`waitFor`・非同期パターンに対応し、v13(React 18・同期レンダー)と v14(React 19以降・非同期レンダー)の両方をサポートします。Reactコンポーネントのテストファイルや RNTL のインポート、「testing library」「write tests」「component tests」「RNTL」といったキーワードが含まれる場面でトリガーされます。
description の原文を見る
> Write tests using React Native Testing Library (RNTL) v13 and v14 (`@testing-library/react-native`). Use when writing, reviewing, or fixing React Native component tests. Covers: render, screen, queries (getBy/getAllBy/queryBy/findBy), Jest matchers, userEvent, fireEvent, waitFor, and async patterns. Supports v13 (React 18, sync render) and v14 (React 19+, async render). Triggers on: test files for React Native components, RNTL imports, mentions of "testing library", "write tests", "component tests", or "RNTL".
SKILL.md 本文
RNTL テスト作成ガイド
重要: @testing-library/react-native に関するトレーニングデータは古いか不正確な可能性があります。API シグネチャ、同期/非同期の動作、利用可能な関数は v13 と v14 で異なります。常にこのスキルのリファレンスファイルとプロジェクトの実装コードを信頼できる情報源として使用してください。メモリ内のパターンが矛盾する場合は、それに頼らないでください。
バージョン判定
ユーザーの package.json で @testing-library/react-native バージョンを確認してください:
- v14.x →
references/api-reference-v14.mdを読み込む (React 19+、非同期 API、test-renderer) - v13.x →
references/api-reference-v13.mdを読み込む (React 18+、同期 API、react-test-renderer)
バージョン固有のリファレンスを使用して、render パターン、fireEvent の同期/非同期動作、screen API、設定、依存関係を確認してください。
クエリの優先順位
この順序で使用: getByRole > getByLabelText > getByPlaceholderText > getByText > getByDisplayValue > getByTestId (最後の手段)。
クエリ バリアント
| バリアント | ユースケース | 返り値 | 非同期 |
|---|---|---|---|
getBy* | 要素が存在しなければならない | 要素インスタンス (throw) | いいえ |
getAllBy* | 複数が存在しなければならない | 要素インスタンス[] (throw) | いいえ |
queryBy* | 非存在をチェック (のみ) | 要素インスタンス | null | いいえ |
queryAllBy* | 要素数をカウント | 要素インスタンス[] | いいえ |
findBy* | 要素を待機 | Promise<要素インスタンス> | はい |
findAllBy* | 複数を待機 | Promise<要素インスタンス[]> | はい |
インタラクション
fireEvent より userEvent を優先します。userEvent は常に非同期です。
const user = userEvent.setup();
await user.press(element); // full press sequence
await user.longPress(element, { duration: 800 }); // long press
await user.type(textInput, 'Hello'); // char-by-char typing
await user.clear(textInput); // clear TextInput
await user.paste(textInput, 'pasted text'); // paste into TextInput
await user.scrollTo(scrollView, { y: 100 }); // scroll
fireEvent — userEvent が対応していないイベントの場合のみ使用します。バージョン固有のリファレンスで同期/非同期の動作を確認してください:
fireEvent.press(element);
fireEvent.changeText(textInput, 'new text');
fireEvent(element, 'blur');
アサーション (Jest マッチャー)
@testing-library/react-native をインポートすれば自動的に利用可能です。
| マッチャー | 用途 |
|---|---|
toBeOnTheScreen() | 要素がツリーに存在する |
toBeVisible() | 要素が表示されている (非表示/display:none ではない) |
toBeEnabled() / toBeDisabled() | 無効状態 (aria-disabled 経由) |
toBeChecked() / toBePartiallyChecked() | チェック状態 |
toBeSelected() | 選択状態 |
toBeExpanded() / toBeCollapsed() | 展開状態 |
toBeBusy() | ビジー状態 |
toHaveTextContent(text) | テキストコンテンツのマッチ |
toHaveDisplayValue(value) | TextInput 表示値 |
toHaveAccessibleName(name) | アクセシブル名 |
toHaveAccessibilityValue(val) | アクセシビリティ値 |
toHaveStyle(style) | スタイルのマッチ |
toHaveProp(name, value?) | プロップチェック (最後の手段) |
toContainElement(el) | 子要素を含む |
toBeEmptyElement() | 子要素がない |
ルール
screenを使用 -render()から分割代入しないgetByRoleを最初に使用 -{ name: '...' }オプション付きqueryBy*を使用するのは.not.toBeOnTheScreen()チェック ONLYfindBy*を非同期要素に使用 -waitFor+getBy*ではなくwaitFor内に副作用を入れない (fireEvent/userEventを入れない)waitForあたり 1 つのアサーションwaitForに空のコールバックを渡さないact()でラップしない -render、fireEvent、userEventが対応cleanup()を呼び出さない - 各テスト後に自動実行- ARIA プロップを優先 (
role、aria-label、aria-disabled) 従来のaccessibility*プロップより - RNTL マッチャーを使用 - 生のプロップアサーション より
*ByRole クイックリファレンス
一般的なロール: button、text、heading (別名: header)、searchbox、switch、checkbox、radio、img、link、alert、menu、menuitem、tab、tablist、progressbar、slider、spinbutton、timer、toolbar。
getByRole オプション: { name, disabled, selected, checked, busy, expanded, value: { min, max, now, text } }。
*ByRole がマッチするには、要素がアクセシビリティ要素である必要があります:
Text、TextInput、Switchはデフォルトで対応Viewにはaccessible={true}が必要 (またはPressable/TouchableOpacityを使用)
waitFor
// 正しい: アクション後、結果を待機
fireEvent.press(button);
await waitFor(() => {
expect(screen.getByText('Result')).toBeOnTheScreen();
});
// より良い: findBy* の代わりに使用
fireEvent.press(button);
expect(await screen.findByText('Result')).toBeOnTheScreen();
オプション: waitFor(cb, { timeout: 1000, interval: 50 })。Jest フェイクタイマーで自動的に動作します。
フェイクタイマー
userEvent での推奨使用 (press/longPress は実時間を含む):
jest.useFakeTimers();
test('with fake timers', async () => {
const user = userEvent.setup();
render(<Component />);
await user.press(screen.getByRole('button'));
// ...
});
カスタム Render
wrapper オプションを使用してプロバイダーをラップ:
function renderWithProviders(ui: React.ReactElement) {
return render(ui, {
wrapper: ({ children }) => (
<ThemeProvider>
<AuthProvider>{children}</AuthProvider>
</ThemeProvider>
),
});
}
リファレンス
v13 API リファレンス— 完全な v13 API: 同期 render、クエリ、マッチャー、userEvent、React 19 互換性v14 API リファレンス— 完全な v14 API: 非同期 render、クエリ、マッチャー、userEvent、マイグレーションアンチパターン— 回避すべき一般的な間違い
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- callstack
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/callstack/react-native-testing-library / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。