mobile-component-testing-with-rntl

Mobile Component Testing with RNTL

Overview

Test React Native components with @testing-library/react-native: write a failing test first (RED), make it pass with the minimum implementation (GREEN), then refactor. Query the rendered tree the way a user or an accessibility tool would — by visible text, accessible role, rendered output — never by inspecting component internals. RNTL renders components in a JS-only environment, so tests are fast and do not require a simulator or device.

When to Use

• The Build phase of an ai-crew run is implementing or modifying a React Native component, screen, or custom hook.
• The developer subagent has been dispatched a task whose Skills to read first list includes this file.
• A test for a React Native component is missing or broken.
• The test-driven-development skill is in play and the surface under test is a React Native component (not a Node-side function).

When NOT to use:

• Pure JS/TS utility functions with no React surface — use plain Jest, no RNTL.
• Backend or Next.js work — use the appropriate web testing skill.
• End-to-end flows (multi-screen navigation, real device, real network) — RNTL renders in isolation and does not exercise navigation or networking; use a dedicated end-to-end testing approach for those.

Process

This skill is a specialization of test-driven-development. The RED→GREEN cycle is:

1. RED — Write a failing RNTL test that describes what the component should render or do, from a user's perspective. Run it. Confirm it fails for the right reason (component doesn't exist yet, or doesn't render the expected text, or doesn't fire the expected callback).
2. GREEN — Write the minimum component code needed to make the test pass. Run the test. Confirm it passes.
3. REFACTOR — Clean up the component. Run the test again. It should still pass.

Repeat for each acceptance criterion. One assertion per test is the default; group only when you're testing the same render output from multiple angles.