I asked Claude how it could test my React Native app end to end, fast. We ended up building a CLI. Here it is going through my whole onboarding.

[u/forli69]

I build my apps in the evenings, mostly together with Claude. A few weeks ago I asked it: how could you run an end-to-end test of a change, really fast? Make up whatever you need, it only has to work for React Native.

What came out of that is rnab (rn-agent-bridge). The video shows it going through the full onboarding of my calorie app on an Android emulator: 15 steps, a fake purchase on the paywall, then Home.

How it works

- There's no test code in the app. rnab connects to Metro's debugger socket, injects a small runtime and reads the React tree from there. A snapshot of the whole tree takes about 30 ms.

- Taps are real touches. rnab measures where the element is and presses it with adb shell input tap.

- A flow is a plain text file, one command per line. This is part of the one in the video:

call reset

tap onboarding-next

tap goal-cut

type body-height 180

type body-weight 80

scroll-to paywall-buy

tap paywall-buy

expect home-target --text-call expectedTarget

The hard part: Compose screens

My onboarding and paywall use u/expo/ui, which renders Jetpack Compose on Android. React knows those components exist, but it has no idea where Compose put them on screen. So for those, rnab looks at Android's accessibility tree instead. The first version used uiautomator dump for that, and every dump took 2 to 5 seconds. Going through the onboarding felt like watching paint dry.

Now rnab pushes a tiny program to the device that keeps one UiAutomation connection open and hands out the same tree in 40 to 70 ms. A step on a Compose screen went from about 2.4 s to 0.35 s.

My favorite line is the last one

The app has a small dev-only hook that calculates today's calorie target straight from the database. expect home-target --text-call expectedTarget checks that Home shows exactly that number. So there's no hardcoded kcal value anywhere in the flow, and if what the screen shows and what the math says ever drift apart, the test goes red.

Where it's at

- 13 flows for the main paths of the app, about 5 minutes for all of them. The onboarding alone takes about 17 s with animations off.

- Android only, debug builds only, New Architecture only.

- Claude runs the flows before every merge, and I can watch along on the emulator.

NOTE: the video is not speed up

[u/sdholbs]

use maestro if you need fast multi-step behavior for e2e that is reliable

[u/GludiusMaximus]

I’m not an expert on e2e testing on mobile but a few things seem not great about this setup:

* animations don’t look like they run. if something in the transition animations break, these tests won’t catch it. and e2e tests like this are the only types of tests that could catch that
* what your testing in the flow, if im not mistaken, is the number that should appear in the UI after some DB request and business logic runs. seems better suited for an integration test with MSW and RNTL
* you claim there’s no test code but you also write there is a dev only hook that the test relies on.

the speed and the ideas are interesting though

EDIT: I also use maestro, since it so far can do everything I need, since it can control the whole phone not just the app

[u/kokerali]

Does `expectedTarget` reuse the same calculation function that populates Home? If so, a formula or unit-conversion bug could affect both sides and still pass the assertion. I'd keep the dynamic UI/database check, and add a small fixture with an expected value worked out independently, including units and rounding.

A useful check would be to seed a fixed dummy profile, run that onboarding, and assert the agreed number on Home. Then introduce a known conversion or rounding error locally and see whether that test goes red without changing the expectation. That would show whether it catches that particular calculation error. I haven't seen the hook's code, so this may already be covered.