What the agent does
The agent locates the application package before choosing a test command. In infinitered/ignite, the Expo application lives under boilerplate rather than the repository root. boilerplate/package.json declares Expo 55.0.5, React Native 0.83.2, React Native Testing Library and a test script that runs Jest. The agent inventories the components, their existing tests and their state or conditional branches, then chooses five targets with behavior worth protecting. A generator test at the repository root is not a substitute for the application's component suite.
The source offers concrete candidates. boilerplate/app/components/TextField.tsx derives disabled behavior from editable and status, supports helper text and conditionally renders accessories. Toggle/Toggle.tsx chooses a non-touchable wrapper when disabled and requests the next value through onValueChange. Button.tsx exposes a disabled accessibility state and optional accessories. The agent reads those contracts before writing interactions, so a test asserts what a person can type, press or see rather than counting implementation branches.
Other useful boundaries appear in Header.tsx and ListItem.tsx. The header can render a title, text actions, icons or supplied action components, while a list item chooses its interactive wrapper from the supplied handlers. The agent ranks these candidates against the rest of your app rather than declaring that every named shared component must be selected. For controlled inputs such as Toggle, it uses a small state-owning render harness so a user interaction can produce a visible updated value instead of pretending the component manages its own state.
It follows boilerplate/jest.config.js, which uses the jest-expo preset and test/setup.ts. The existing Text.test.tsx demonstrates rendering with ThemeProvider and NavigationContainer. New tests preserve those real application wrappers and use React Native Testing Library queries and interactions. The agent runs the selected files and then the application suite with a non-watching Jest invocation, such as npm test -- --runInBand from boilerplate after installing its dependencies. Native platform setup and existing test doubles are disclosed; a Jest pass is not described as an iOS or Android device test.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Find the five components in this Expo app with the most meaningful conditional rendering or state that lacks useful tests. Locate the actual application package, not a surrounding generator package, and read its Jest setup and existing component specs. Write React Native Testing Library tests that render the real components with required application providers, interact as a user would and assert visible output or accessibility state. Use a state-owning harness for controlled inputs and cover relevant disabled behavior. Do not mock the components or change production behavior. Run focused tests and the application Jest suite without watch mode. Open a pull request explaining the selected components, behaviors covered, exact commands and any native-device limits.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
The pull request contains focused component tests beside the selected Expo source. Its summary explains why each component was chosen and which visible behavior the tests protect, such as text input, a disabled action, a helper message or a controlled toggle transition. Provider setup is shared only where the existing suite supports it. Large snapshots and direct calls to component internals do not stand in for interaction assertions.
A reviewer checks that user actions reach the actual component and that controlled values change through their parent harness. They confirm disabled interactions cannot trigger the normal action and that labels or roles used by queries reflect the accessible interface. The result names the application directory and Jest commands, records focused and wider results separately, and states that platform layout, keyboard behavior and device integration may still need native testing.
Run it on every component behavior change
Call the sessions API from your PR workflow when a shared component gains new state or conditional UI. Replace the example resource URL with your connected repository and include the application subdirectory and intended interaction in the prompt. An open PR URL can target the current change. Read the session answer for the test diff, or use a webhook configured on your API key to notify the reviewer when the turn finishes.
The use case this job follows, with its automation and trigger: Write the missing tests.
Why run it on Rush?
Component tests often fail first on provider setup, module transforms or native dependencies rather than on the behavior they were written to check. Rush gives the agent its own sandbox to prepare that environment and rerun the actual Jest suite. The developer can keep working in their Expo session instead of changing local dependencies to investigate test setup.
The retained command output makes the resulting PR more useful than a batch of plausible test files. Reviewers can see whether the agent ran the application package or only the surrounding repository's tests. Separate sessions can examine multiple apps without mixing their Expo versions, Jest presets or temporary state, while the final decision stays with the person reviewing the behavior.
Frequently asked questions
Will it choose components just because their files are long?
No, selection should follow meaningful state, conditional rendering and missing coverage. A large styling file can have less behavior to protect than a short controlled input. The PR explains why each selected component deserves tests rather than reporting file size as proof of risk.
How does it test controlled toggles and inputs?
It renders them inside a small parent that owns the value and applies the component's change callback. That allows a user interaction to produce a visible state transition. Calling a callback directly or expecting an unchanged controlled prop to update itself would not test the intended interaction.
Does it replace my components with Jest mocks?
The components under test stay real, together with their application providers where practical. Existing Expo or native-module test setup may still be required to run in Jest, and the report names that boundary. Mocking the component itself would only test the replacement and is outside this request.
Do these tests require an Android emulator or an iPhone?
React Native Testing Library component tests run in the project's Jest environment. They can check rendered text, accessible state and supported interactions without claiming to exercise a device. Native keyboard behavior, platform layout and end-to-end navigation require additional device-level verification.