Testing and releasing
A web fix reaches every user the moment you deploy. A mobile fix has to pass store review, and then each phone installs it when it decides to. This lesson shows you how Mangrove ships the Rider app safely anyway: the right tests at each level, signed store builds, a staged rollout with a written halt rule, and over-the-air updates for the fixes that cannot wait.
By the end you can
- Choose between a unit test, a component test and an end-to-end flow for a given Rider app bug
- Explain what signing a build means on Android and iOS, and what EAS Build does for you in the cloud
- Run a staged rollout on Google Play and a phased release on the App Store, with halt criteria written before you start
- Decide whether a change can ship over the air or needs a new store build, using runtime versions
- Publish, roll out and roll back an EAS Update
The everyday picture
Think about how a Mangrove store changes. Swapping a shelf label or a promotion sign takes a staff member two minutes. Installing a new freezer aisle takes a contractor, a safety inspection and a few weeks. And a label can only describe what the shelves can hold: you cannot put an ice cream sign in a store that has no freezer.
When head office launches a new frozen range, it does not open it in all 320 stores on the same morning. It tries it in ten stores first, with a rule agreed in advance: if freezers fail or waste goes above a set level, the launch stops there. Only when those ten stores look healthy does the range spread to the rest.
A mobile release works the same way. The store build is the freezer aisle: native code, permissions and libraries, slow to change and checked by Apple and Google. The JavaScript bundle is the shelf label: you can replace it over the air in minutes, but only with code that the installed native layer can run. And a staged rollout is the ten-store pilot, with the stop rule written down before anyone starts.
Three levels of test on a phone
The testing pyramid from Errors, debugging and testing holds on mobile, with one extra reason to respect it: every test that needs a phone is slow, and phones are fussy. So most of your checks should run in Node, without any phone at all.
Unit tests cover pure logic: the outbox and its retry rules from Offline first, formatting cash-on-delivery amounts from cents, deciding whether a job is late. An Expo project uses Jest with the jest-expo preset, which mocks the native side of Expo's modules so tests run in plain Node. Hundreds of them run in seconds on every pull request.
Component tests render one screen or component in Node and drive it like a rider would. You already know the approach from Testing React like a user; on mobile you use React Native Testing Library (@testing-library/react-native). You find elements by role and accessible name, press and type with userEvent, and check what appears. In version 14 of the library, render is async, so you write await render(...). Your fake services replace the network and the device, so a component test cannot tell you whether the camera opens on a real phone.
End-to-end (E2E) tests install a real build on an emulator or a phone and tap through it. Two tools are common. Maestro describes a flow as a short YAML file of steps such as "tap on Accept" and "assert visible: Pending sync", and it waits for the screen to settle on its own. Detox is a gray-box tool made for React Native: it knows when the app is idle, and you write the tests in JavaScript. Either way, keep E2E for the one or two flows that must never break. For the Rider app that is accept a job, deliver it with no signal, see it sync. Maestro can switch airplane mode on an Android emulator, so this flow can really go offline. Its setAirplaneMode command does nothing on iOS, because iOS simulators have no airplane mode.
A useful habit: when a bug escapes, ask which level is the cheapest place to catch it, and add the test there. A wrong retry delay belongs in a unit test. A disabled button belongs in a component test. Only a failure that needs the real device, the real build or the real network belongs in E2E.
Quick check
On the job detail screen, the "Confirm delivery" button stays disabled after a rider types a valid one-time code. Where should the regression test go?
The bug lives in how the screen reacts to typing, which a component test reproduces in Node in under a second. An E2E flow would also catch it, but it needs a build and an emulator and is slower to run and debug. The outbox never sees the press, so its unit tests cannot catch this.