How would you split a React Native team's test budget across Jest, component tests and device E2E, and what would make you change the split?

## The question behind the question Every React Native team has the same three layers: **pure Jest tests**, **component tests** with React Native Testing Library, and **device E2E** with Detox, Maestro or Appium. The judgement is not which layers exist but **how much to spend on each**. There is no single right ratio; a principal-level answer shows the cost model, the risk model and the signals that move the line. ## The cost model | Layer | Cost to run | Cost to maintain | What it proves | |---|---|---|---| | Pure Jest | Milliseconds per test, any CI machine | Low | Logic and data handling | | Component (RNTL) | Seconds per suite, any CI machine | Moderate: mocks must track native contracts | Screen behaviour in JavaScript | | Device E2E | Native build per platform, booted simulator or emulator, minutes per flow | High: device state, backend data, flake triage | The app working on a platform | Two costs are easy to miss. **Triage**: a flaky E2E test costs someone's afternoon each time it fails. **Trust**: once developers learn to re-run a red suite, it stops protecting anything. ## The risk model Spend where users get hurt and where cheap layers are blind: - **Vital flows** (sign-in, purchase, anything involving money or data loss) get device coverage on both platforms, as React Native's testing guide recommends for authentication, core functionality and payments. - **Native surface area** (custom native modules, heavy use of native libraries, platform-specific UI) raises the device share, because component tests only see mocks there. - **Pure product logic** (pricing, validation, state machines) is cheapest and most thoroughly covered in Jest. - **Screen behaviour** (states, errors, disabled buttons, accessibility labels) sits in RNTL. ## Release channels change the equation React Native apps can ship in two ways: 1. **A store build**, which rebuilds native code and passes store review. 2. **An over-the-air (OTA) update** of the JavaScript bundle and assets, which cannot change native code and does not go through a new native build or a new store submission. If the team ships OTA often, the fast layers are the main gate for most releases, so their quality bar rises: more component coverage of risky screens, stricter review of mocks. Device suites then concentrate on store builds and on changes that touch native code or dependencies. ## Signals that should move the split - **Escaped defects by layer.** Classify production bugs by the cheapest layer that could have caught them. Many native or layout bugs escaping means too little device coverage; many logic bugs escaping means the fast layers are thin. - **Flake rate.** A device suite failing without code changes more than rarely is a signal to shrink or stabilise it before adding tests. - **Time to signal.** If developers wait too long for feedback on a pull request, move E2E to merge or nightly runs and keep only a smoke flow per pull request. - **Upgrade pain.** React Native upgrades and native dependency bumps that break the app in ways Jest missed argue for a device smoke suite tied to those changes. - **Platform skew.** Bugs appearing on only one platform argue for running vital flows on both, not just the one developers use daily. ## A defensible starting point 1. Every pull request: all Jest and RNTL tests, plus one E2E smoke flow on one platform if builds are fast enough. 2. Merge to main: the vital-flow E2E suite on both platforms. 3. Release candidate: the E2E suite on a small set of real devices. 4. Quarterly: review escaped defects, flake rate and CI time, then move tests between layers. ## What a weak answer sounds like A fixed ratio recited without reasons, "E2E everything for confidence", or "we don't need E2E because coverage is 90 per cent". Coverage percentages measure JavaScript lines executed under mocks; they say nothing about the native half of the app.