Every lesson in this course has pushed logic out of components and into small pure functions: parseDistanceKm, hikesReducer, validateHikeForm, permissionAction, trackDistanceKm. That wasn’t only tidiness. On mobile, checking a change by hand means rebuilding, launching, navigating three screens deep and typing on a simulator keyboard. A test that checks the same thing in 20 milliseconds, every time you save, is the best trade you’ll make.
Expo’s preset, jest-expo, configures Jest for React Native: it transforms your TypeScript and JSX, and mocks the native side of Expo modules, so tests run in Node with no device. Install it and React Native Testing Library:
npx expo install jest-expo jest @types/jest --dev\nnpx expo install @testing-library/react-native --devThen point Jest at the preset in package.json:
{\n \"scripts\": {\n \"test\": \"jest --watchAll\"\n },\n \"jest\": {\n \"preset\": \"jest-expo\"\n }\n}Expo’s guide also lists a transformIgnorePatterns entry for packages that ship untranspiled code; copy it from there when an import fails with “SyntaxError: Cannot use import statement outside a module”. Put tests in __tests__ folders next to the code they cover.
The parser from section 1 has many small rules. A table of cases documents them better than prose:
\nimport { parseDistanceKm } from '../parseDistance';\n\ntest.each([\n ['8.4', 8.4],\n ['8,4', 8.4],\n [' 12 km', 12],\n ['abc', null],\n ['0', null],\n ['1.2.3', null],\n])('parseDistanceKm(%j) is %p', (input, expected) => {\n expect(parseDistanceKm(input)).toBe(expected);\n});Notice that the test cases are exactly the odd inputs you worried about when you wrote the function: the comma decimal, the trailing unit, the zero. Every bug report becomes one more row in a table like this, written before the fix, so the same bug can never quietly return.
\nReducers get the same treatment: build a state, dispatch an action, check the result, and check that the input wasn’t mutated. These tests are fast, stable and need no mocks, which is why they should be most of your suite.
\nReact Native Testing Library renders components in memory and lets you query them the way people perceive them: by role, label and text. Here’s a test for the QuickLog component from section 1:
import { render, screen, userEvent } from '@testing-library/react-native';\nimport { QuickLog } from '../QuickLog';\n\ntest('saves a valid distance', async () => {\n const onSave = jest.fn();\n const user = userEvent.setup();\n await render(<QuickLog onSave={onSave} />);\n\n await user.type(screen.getByLabelText('Distance (km)'), '8,4');\n await user.press(screen.getByRole('button', { name: 'Save' }));\n\n expect(onSave).toHaveBeenCalledWith(8.4);\n});\n\ntest('keeps Save disabled until the distance is valid', async () => {\n const user = userEvent.setup();\n await render(<QuickLog onSave={jest.fn()} />);\n\n await user.type(screen.getByLabelText('Distance (km)'), 'far');\n\n expect(screen.getByRole('button', { name: 'Save' })).toBeDisabled();\n});For getByLabelText to find the input, the TextInput needs accessibilityLabel="Distance (km)". That’s the point: a test that queries by role and label fails when the screen isn’t accessible, so your tests double as an accessibility check. userEvent simulates real interactions (focus, typing each character, press-in and press-out), and in current versions of the library both render and the interactions are async, so await them. Matchers like toBeOnTheScreen(), toHaveTextContent() and toBeDisabled() come with the library.
jest-expo stubs native modules, but stubs return nothing useful. When a component depends on a module’s answer, mock it with the answer you want to test:
import * as Location from 'expo-location';\n\njest.mock('expo-location', () => ({\n getForegroundPermissionsAsync: jest.fn(),\n requestForegroundPermissionsAsync: jest.fn(),\n}));\n\ntest('offers Settings after a permanent denial', async () => {\n jest.mocked(Location.getForegroundPermissionsAsync).mockResolvedValue({\n status: 'denied', granted: false, canAskAgain: false, expires: 'never',\n } as Location.LocationPermissionResponse);\n\n await render(<TrackScreen />);\n\n expect(await screen.findByRole('button', { name: 'Open Settings' })).toBeOnTheScreen();\n});findBy… queries wait for the element to appear, which suits screens that load asynchronously. Mock at the edge of your app (native modules, fetch), not your own components, so the code under test is the code you ship. Screens that use Expo Router hooks can be rendered with renderRouter from expo-router/testing-library, which sets up an in-memory router with the routes you give it.
Unit and component tests can’t catch a broken native build, a permission prompt that never appears, or a keyboard covering the Save button. A few end-to-end tests on real builds cover that: tools such as Maestro (which EAS can run in the cloud) or Detox drive the actual app on a simulator. Keep them for the flows that would hurt most if broken, such as signing in and logging a hike, and let the fast tests cover everything else.
\nNext: turning the tested app into builds that real phones can install.
\n","toc":[{"id":"sec-1","text":"Setting up Jest","level":2},{"id":"sec-2","text":"Start with pure logic","level":2},{"id":"sec-3","text":"Testing components like a user","level":2},{"id":"sec-4","text":"Mocking the device at the boundary","level":2},{"id":"sec-5","text":"Where end-to-end tests fit","level":2}],"takeaways":["The jest-expo preset configures Jest for React Native and mocks the native side of Expo modules, so tests run in Node without a device.","Pure functions such as parsers, reducers and validators give the most confidence per minute of test-writing; test them first.","React Native Testing Library renders components and lets you find elements by role, label and text, the way users and screen readers do.","In current versions of the library,render and userEvent interactions are async; await them.","Mock native modules like expo-location at the boundary with jest.mock, and assert on what the user sees."],"further":[{"title":"Unit testing with Jest","url":"https://docs.expo.dev/develop/unit-testing/"},{"title":"React Native Testing Library","url":"https://testing-library.com/docs/react-native-testing-library/intro/"},{"title":"Jest mock functions","url":"https://jestjs.io/docs/mock-functions"}],"quiz":[{"q":"Which Trailhead test gives the most confidence for the least effort?
","options":[{"text":"A snapshot of the whole hike log screen.","why":"Snapshots break on every harmless markup change and pass happily when the logic is wrong. People learn to update them without reading."},{"text":"An end-to-end test that taps through the app on a simulator to check that “8,4” is parsed.","why":"End-to-end tests are valuable for critical flows, but they’re slow and flaky for checking one parsing rule."},{"text":"A table of inputs and expected outputs forparseDistanceKm and hikesReducer.","why":"Correct. Pure functions run in milliseconds, need no mocks, and cover the rules users depend on."}],"answer":2},{"q":"How should a component test find Trailhead’s Save button?
","options":[{"text":"screen.getByRole('button', { name: 'Save' })","why":"Correct. It finds what users and screen readers see, and it fails if you forget the button role, which is a real accessibility bug."},{"text":"screen.getByTestId('save-btn-3')","why":"Test ids work, but they test an implementation detail and miss accessibility problems. Use them as a last resort."},{"text":"By reading the third child of the rendered tree’s root View.","why":"That breaks whenever layout changes, even when the app still works."}],"answer":0},{"q":"A component calls Location.getForegroundPermissionsAsync(). In a Jest test it returns undefined and the component shows a spinner forever. What’s the right fix?
process.env.NODE_ENV is test.","why":"Test-only branches in production code mean you’re no longer testing the code you ship."},{"text":"Wrap the call in try/catch so the test passes.","why":"Nothing throws here; the mock just returns nothing. A catch changes nothing and hides real errors."},{"text":"Mock the module with jest.mock('expo-location', …) so the function resolves with a permission response you choose.","why":"Correct. You control the boundary and can test each state (granted, denied, and permanently denied)."}],"answer":3}],"exercise":{"kind":"fill","language":"tsx","template":"import { render, screen, userEvent } from '@testing-library/react-native';\nimport { HikeForm } from '../HikeForm';\n\ntest('shows an error, then saves once the distance is fixed', async () => {\n const onSave = jest.fn();\n const user = userEvent.{{0}}();\n await {{1}}(Fill in the blanks in this React Native Testing Library test for Trailhead’s HikeForm. It should set up user events, render the form, press the Save button found by its role, check that the distance error appears on screen, and finally check that onSave received the right hike.
userEvent needs a one-time call that returns the user object, and the component is mounted with the library’s main function.","Users press buttons; the query looks for the accessibility role a Pressable gets from accessibilityRole.","One matcher checks an element is on the screen; the other checks a mock function received specific arguments."],"explanation":"userEvent.setup() creates a user that types and presses like a real person, and await render(...) mounts the form (both are async in current versions of the library). getByRole('button', { name: 'Save' }) finds the button the way a screen reader does, so the test also guards accessibility. toBeOnTheScreen() asserts the validation message rendered, and toHaveBeenCalledWith(expect.objectContaining(...)) checks the saved hike without depending on fields the test doesn’t care about, such as the generated id.