使用 React Native Testing Library 渲染组件
使用 @testing-library/react-native 中的 render 挂载组件,通过文本或 testID 查询元素,并断言预期内容可见。
使用 React Native Testing Library 渲染组件 是 CoddyKit 上的免费 React Native Academy 课时。 这是第 2 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 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 渲染组件」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 React Native Academy 课程的其余内容,请升级到 CoddyKit PRO。 React Native Academy 课程共包含 4 节课。
「使用 React Native Testing Library 渲染组件」这节课中我会学到什么?
使用 @testing-library/react-native 中的 render 挂载组件,通过文本或 testID 查询元素,并断言预期内容可见。 你通过在浏览器中直接运行的动手代码来练习 React Native Academy,全天候 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 渲染组件
- 触发事件与测试用户交互
- 模拟原生模块与异步代码