React Native E2E Testing Without Detox or a Device Farm
Run e2e tests on a React Native app without Detox setup or your own simulators: upload a build, describe flows in English, get recordings on every PR.
End-to-end testing is where React Native teams stall. Unit tests are easy and component tests are fine, but running the real app through real user flows means picking a framework with native build integration, standing up simulators in CI, and maintaining test code from then on. Many teams evaluate that stack, file it under "later", and ship on manual checks. This guide covers what the conventional options actually require, and then the path that skips most of it.
What e2e means for a React Native app
An end-to-end test installs your actual build in an iOS simulator or Android emulator and performs a user journey against it: launch, onboard, sign in, do the thing your app exists for. It catches what component tests structurally cannot: navigation breaks, native-module issues surfacing in real flows, a login that works on iOS and dies on Android. For apps, the stakes are higher than on web, because there is no quick rollback once a broken build reaches the stores.
The conventional stack, honestly summarized
Detox (by Wix) is the established RN framework: gray-box, synchronized with the app, fast when configured well. The cost is the configuration: native integration in your app, per-platform build variants, environment setup, JavaScript test code, and CI with macOS runners for iOS simulators. Our full comparison is at TesterArmy vs Detox.
Maestro trades power for simplicity with YAML flow files and easier setup, and you still own flow files, selectors by testID, and the infrastructure question.
Appium brings the WebDriver model to mobile, with maximum flexibility and the steepest setup and maintenance of the three.
The shared shape: whichever you pick, you acquire a test codebase, an infrastructure bill (macOS CI minutes for iOS are the expensive kind), and a maintenance loop when the UI changes.
The agent path: upload a build, describe the flow
TesterArmy replaces that stack with two inputs. First, a simulator build of your app (an iOS .app bundle or Android APK); if you use Expo, EAS produces this automatically, and our Expo EAS guide has the complete pipeline including PR wiring. Second, flows in plain English: "launch the app, sign up with email, complete the onboarding tour, add an item and check out."
The agent installs the build in a managed cloud simulator and performs the flow by looking at the screen the way a user does, so there are no testIDs to sprinkle, no matchers to write, and nothing that breaks when a screen is rebuilt. Logins work like real logins, including one-time codes retrieved from managed email inboxes and SMS numbers. Each run produces a full video recording, screenshots at every step, and a pass/fail step trace; wired to GitHub, results land as a check and a PR comment, so a broken flow is a red check with a recording attached rather than a bug report from a user.
Stated plainly, because it matters: runs execute on iOS simulators and Android emulators. That covers UI, flow, and regression testing well, and it is the same practical coverage a standard Detox setup gives you. Hardware-specific behavior (camera, biometrics, device-specific performance) still needs on-device testing, with TesterArmy or without it.
A sensible rollout for an RN team
- Produce a simulator build (manually first; automate via EAS or your CI once it works).
- Describe your top three journeys in plain English. Start with login, because if login breaks nothing else matters.
- Run them on demand until you trust the results, then connect GitHub and let every PR trigger the runs.
- Add scheduled runs against your staging build for the flows that PRs do not touch daily.
Teams typically have step 1 and 2 running the same afternoon; the 5 free runs exist exactly for that experiment.
FAQ
Can you do e2e testing in React Native without Detox? Yes. Agent-based platforms run your real build in cloud simulators from an upload, with flows described in plain English instead of test code and native integration.
Does this work with Expo? Yes; EAS builds the simulator app and hands it over automatically. See the Expo EAS pipeline guide.
What about testing on real devices? Simulators and emulators cover UI and flow regressions, which is where apps break week to week. Keep a manual on-device pass for hardware features and release candidates.
How is this different from Maestro's YAML flows? YAML flows are still code you own, with selectors that bind to the UI. Plain-English flows are interpreted by the agent against the rendered screen on every run, so a redesigned screen is handled rather than breaking a flow file.
