React Native Testing Libraryによるコンポーネントのレンダリング
@testing-library/react-nativeのrenderでコンポーネントをマウントし、テキストまたはtestIDで要素を検索します。期待するコンテンツが表示されていることをアサートします。
「React Native Testing Libraryによるコンポーネントのレンダリング」はCoddyKit上の無料React Native Academyレッスンです。 これはレッスン2/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはReact Native Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 React Native Academyコースには全4レッスンが含まれています。
このレッスンの一部はまだ翻訳されておらず、英語で表示されています。
What Is React Native Testing Library?
React Native Testing Library (RNTL) is the standard tool for writing component tests in React Native. It lets you render a component in a simulated environment, query the output for elements, and make assertions about what the user would see.
RNTL follows the Testing Library philosophy: test components the way users interact with them — by visible text, accessibility labels, and roles — rather than by internal implementation details like component names or state values. This produces tests that are resilient to refactoring.
Installing React Native Testing Library
Install RNTL and its peer dependency @testing-library/jest-native for extended matchers. The jest-native package adds React Native-specific matchers like toBeVisible() and toHaveTextContent().
Add the setup file to your Jest config so the matchers are available in every test file without manual imports. Import @testing-library/jest-native/extend-expect in the Jest setup file.
npm install --save-dev @testing-library/react-native @testing-library/jest-native
// jest.config.js — add setup file
module.exports = {
preset: 'jest-expo',
setupFilesAfterFramework: ['@testing-library/jest-native/extend-expect'],
};
// Or in package.json:
'jest': {
'preset': 'jest-expo',
'setupFilesAfterFramework': ['@testing-library/jest-native/extend-expect']
}Rendering a Component with render()
The render() function from RNTL mounts a component and returns a set of query utilities for inspecting the rendered output. It takes JSX just like you would write in your app, including any props or wrapping providers needed.
The returned object includes query methods and a debug() function that prints the rendered component tree to the console. Call debug() at any point during a test to see what the component looks like at that moment.
import { render } from '@testing-library/react-native';
import { Greeting } from '../src/components/Greeting';
describe('Greeting', () => {
it('displays the correct greeting message', () => {
const { getByText, debug } = render(<Greeting name='Alice' />);
// Print the component tree for debugging
debug();
// Assert that the text 'Hello, Alice!' is visible
expect(getByText('Hello, Alice!')).toBeTruthy();
});
});Querying by Text with getByText
getByText(text) finds an element that displays the exact text string. It throws if no matching element is found (failing the test) or if multiple elements match. Use queryByText when you want to assert the text is not present (it returns null instead of throwing).
You can also pass a regular expression to match partial text: getByText(/Hello/). This is useful when the text includes dynamic values like a username that you do not want to hard-code in the test.
import { render } from '@testing-library/react-native';
import { PostCard } from '../src/components/PostCard';
it('renders the post title and author', () => {
const { getByText, queryByText } = render(
<PostCard title='My First Post' author='Alice' isDeleted={false} />
);
// getByText throws if not found
expect(getByText('My First Post')).toBeTruthy();
expect(getByText('Alice')).toBeTruthy();
// queryByText returns null if not found — use for absence checks
expect(queryByText('Deleted')).toBeNull();
});Querying by testID
When there is no user-visible text to query by, add a testID prop to the element and query it with getByTestId('testID'). This is useful for icons, images, loading indicators, and container views.
Keep testID values consistent with the component they identify. A naming convention like componentName-element (e.g., profileCard-avatar) makes test IDs self-documenting and prevents collisions across the test suite.
// Component:
export function LoadingScreen() {
return (
<View testID='loading-screen'>
<ActivityIndicator testID='loading-spinner' />
<Text>Loading your data...</Text>
</View>
);
}
// Test:
import { render } from '@testing-library/react-native';
it('shows a loading spinner', () => {
const { getByTestId } = render(<LoadingScreen />);
const spinner = getByTestId('loading-spinner');
expect(spinner).toBeTruthy();
});Accessibility Queries
RNTL encourages querying by accessibility attributes because these are what screen readers use, making your tests also verify accessibility. The key accessibility queries are:
getByRole('button', { name: 'Submit' })— finds an element by its ARIA role and accessible namegetByLabelText('Email')— finds an element with a matchingaccessibilityLabelgetByPlaceholderText('Enter email')— finds a TextInput by its placeholder
it('has an accessible submit button', () => {
const { getByRole, getByLabelText, getByPlaceholderText } = render(
<LoginForm />
);
// Find by role (button)
const submitButton = getByRole('button', { name: 'Sign In' });
expect(submitButton).toBeTruthy();
// Find TextInput by placeholder
const emailInput = getByPlaceholderText('Enter your email');
expect(emailInput).toBeTruthy();
// Find by accessibility label
const passwordInput = getByLabelText('Password');
expect(passwordInput).toBeTruthy();
});Asserting with jest-native Matchers
@testing-library/jest-native extends Jest with semantic matchers that are easier to read and more meaningful than checking raw props. Key matchers include:
toBeVisible()— element is not hiddentoHaveTextContent('text')— element contains the given texttoBeDisabled()— button or input is disabledtoHaveStyle({ color: 'red' })— element has the specified style
import { render } from '@testing-library/react-native';
import { StatusBadge } from '../src/components/StatusBadge';
it('shows an error badge in red when status is error', () => {
const { getByTestId } = render(<StatusBadge status='error' />);
const badge = getByTestId('status-badge');
expect(badge).toBeVisible();
expect(badge).toHaveTextContent('Error');
expect(badge).toHaveStyle({ backgroundColor: '#ff4444' });
});Rendering with Providers
Most real-world components depend on context providers like NavigationContainer, Redux Provider, or custom ThemeContext. If you render a component without its required providers, the test will throw.
Create a custom renderWithProviders utility that wraps components in all the necessary providers. Pass this utility to RNTL's render option via wrapper, or use it as a drop-in replacement for render across your test suite.
// test-utils.tsx
import { NavigationContainer } from '@react-navigation/native';
import { ThemeProvider } from '../src/context/ThemeContext';
export function renderWithProviders(
ui: React.ReactElement,
options = {}
) {
function Wrapper({ children }: { children: React.ReactNode }) {
return (
<NavigationContainer>
<ThemeProvider>
{children}
</ThemeProvider>
</NavigationContainer>
);
}
return render(ui, { wrapper: Wrapper, ...options });
}
// In tests:
import { renderWithProviders } from '../test-utils';
const { getByText } = renderWithProviders(<ProfileScreen />);Snapshot Testing
Snapshot tests capture the rendered output of a component and save it to a .snap file. On subsequent runs, Jest compares the current output against the saved snapshot and fails the test if they differ. This catches unintentional UI changes.
Use snapshots sparingly. They are great for small, stable components like icons or buttons. For complex screens, snapshot tests tend to be brittle — minor, intentional changes require updating the snapshot with jest --updateSnapshot, making it easy to accidentally accept broken output.
import { render } from '@testing-library/react-native';
import { PrimaryButton } from '../src/components/PrimaryButton';
it('renders a primary button correctly', () => {
const { toJSON } = render(<PrimaryButton title='Save' onPress={() => {}} />);
expect(toJSON()).toMatchSnapshot();
});
// First run creates:
// __snapshots__/PrimaryButton.test.tsx.snap
// Subsequent runs compare against that snapshotTesting Conditional Rendering
Components often render different UI based on props or state. Test each conditional branch explicitly by rendering the component with different props and asserting that the correct elements are present or absent.
Use queryByText or queryByTestId (which return null instead of throwing) to assert absence. Avoid using getBy queries to assert absence — they throw, which does not produce a clear failure message.
describe('ErrorBanner', () => {
it('shows the error message when error prop is provided', () => {
const { getByText } = render(
<ErrorBanner error='Something went wrong' />
);
expect(getByText('Something went wrong')).toBeTruthy();
});
it('renders nothing when error is null', () => {
const { queryByTestId } = render(<ErrorBanner error={null} />);
// Assert the banner container is NOT rendered
expect(queryByTestId('error-banner')).toBeNull();
});
});The getAllBy and findBy Variants
RNTL query functions come in three variants:
- getBy — throws if not found or if multiple matches (use for single, must-exist elements)
- getAllBy — returns an array, throws if none found (use for lists of elements)
- findBy — returns a Promise, waits for the element to appear (use for async content)
The findBy variants are essential when testing components that load data asynchronously — they automatically retry the query until the element appears or a timeout is exceeded.
// getAllBy: asserts there are exactly 3 list items
const items = getAllByTestId('list-item');
expect(items).toHaveLength(3);
// findBy: waits for async content to appear
it('shows posts after loading', async () => {
const { findByText } = render(<PostFeed />);
// Waits up to 1000ms for the text to appear
const postTitle = await findByText('My First Post');
expect(postTitle).toBeTruthy();
});Quick Check
Test your understanding of React Native Mobile Development concepts from this lesson.
Lesson Recap
In this lesson you learned: how to render components with RNTL's render() function and query elements by text, testID, and accessibility attributes, how jest-native matchers like toBeVisible() and toHaveTextContent() make assertions more readable, and how to wrap components in providers for tests that require navigation or theme context. Next up we fire user events and test interactive component behavior.
よくある質問
「React Native Testing Libraryによるコンポーネントのレンダリング」レッスンは無料ですか?
はい。「React Native Testing Libraryによるコンポーネントのレンダリング」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し(組み込みコードエディタと24時間対応のAIチューター)、React Native Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 React Native Academyコースには全4レッスンが含まれています。
「React Native Testing Libraryによるコンポーネントのレンダリング」で何を学びますか?
@testing-library/react-nativeのrenderでコンポーネントをマウントし、テキストまたはtestIDで要素を検索します。期待するコンテンツが表示されていることをアサートします。 ブラウザで直接実行するハンズオンコードでReact Native Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
React Native Academyを始めるのに経験は必要ですか?
事前経験は必要ありません。CoddyKitのReact Native Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン2/4です。
「React Native Testing Libraryによるコンポーネントのレンダリング」レッスンにはどのくらい時間がかかりますか?
ほとんどのCoddyKitレッスンは約5~10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このReact Native Academyレッスンでコードを書いて実行できますか?
はい。すべてのReact Native Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- React NativeプロジェクトでのJestのセットアップ
- React Native Testing Libraryによるコンポーネントのレンダリング
- イベント発火とユーザー操作のテスト
- ネイティブモジュールと非同期コードのモック