skip to content

In Detox, what does the default app reinstall do for isolation between test files, and when is --reuse acceptable?

level: middleimportance: should knowfreq 35%

answer

  1. reinstall per test file by default
  2. behavior.init.reinstallApp
  3. --reuse keeps the installed app
  4. disk state leaks between files
  5. JS-only local loop with Metro

basics

~20 s

By default Detox uninstalls and reinstalls the app for each test file, so every file starts without stored data. --reuse skips that for speed, letting app data and a stale binary carry over, which suits a local JS-only loop but not CI.

solid answer

~40 s

With the default `behavior.init.reinstallApp: true`, each test file's Detox worker uninstalls and reinstalls the app, so the file starts clean: no saved session, no stored drafts, and the freshly built binary. `--reuse` sets that to `false`; it saves the reinstall time but carries over whatever is installed — an old native build and every byte earlier files wrote. Detox recommends it for a debug build on Metro while writing tests, and warns against it after native changes or when the app uses disk storage. On CI I keep the default, because reuse makes files order-dependent and parallel runs random. Isolation inside a file, and on the backend, still needs resets and separate test data.

code

bash · 5 lines
bash
# local loop on a debug build, JS-only changes, Metro running
detox test -c ios.sim.debug --reuse e2e/booking.test.js

# CI: default reinstall per file
detox test -c ios.sim.release

go deeper

for a junior

Recall that Detox reinstalls the app per test file by default and that --reuse skips it for speed.

for a middle

Explain what reinstall clears, what --reuse carries over, and why that makes files order-dependent.

for a senior

Keep CI on reinstall, design per-file and per-test data so files are order-independent, and use --reuse only for local JS iteration.

for a principal

Weigh reinstall cost against isolation across a large suite and decide where resets belong: device, app or backend.

## The default: a fresh install for every test file When the **Detox** Jest environment sets up a test file, Detox initialises a worker for it, and with the default `behavior.init.reinstallApp: true` that worker **uninstalls and reinstalls the app** before the file's tests run. Every file therefore starts with no stored data: no AsyncStorage entries, no database rows, no saved login, no draft booking. That default is the main source of **isolation between test files** in Detox. It is also a cost: an uninstall-install cycle per file adds seconds to every file, more on a slow CI emulator. ## What `--reuse` changes `detox test --reuse` (`-r`) sets `reinstallApp` to `false`: Detox keeps whatever app is already installed. The consequences: - **Faster runs.** No reinstall per file. - **Stale binary risk.** If native code changed and the device still has the old install, the tests run the old native code. - **State leaks between files.** Whatever one file leaves on disk — a signed-in session in secure storage, a cached search, a pending reservation — is there when the next file starts. The Detox guide on developing while writing tests recommends `--reuse` for exactly one workflow: running a **debug** build connected to Metro, where JavaScript changes arrive over the network and the binary does not change. It also says not to use it after native code changes, or when the app relies on local (disk) storage. | | Default (reinstall) | `--reuse` | |---|---|---| | App binary | freshly installed per file | whatever is already installed | | Stored app data | cleared per file | carried over between files | | Speed | slower | faster | | Good for | CI, any suite with stored state | local iteration on JS-only changes | ## Why CI should keep the default 1. **Order independence.** With reuse, a file can pass only because an earlier file signed in or seeded data. Change the order, shard the suite or run in parallel, and it fails — a classic "passes locally, fails on CI" pattern. 2. **Parallel workers.** Files are spread across workers and devices in no fixed order, so any dependency between files becomes random. 3. **The binary under test.** CI builds a fresh binary; reinstalling guarantees that is what runs. ## Isolation inside a file is a separate concern Reinstalling per file does not isolate tests **within** a file. Common patterns are: - **A known starting screen** for each test, through `device.reloadReactNative()` or a relaunch in `beforeEach`. - **Explicit data resets** for tests that need a new user, through the device API's launch options that reset or delete app data. - **Independent backend data** per file and per test — a separate guest account and distinct dates for each booking test — so server-side state cannot leak either. The last point matters because a reinstall clears the device, not the server: two files that book "the same room on the same night" still collide on the backend. ## In the hotel-booking suite - `e2e/search.test.js` searches as a guest. - `e2e/booking.test.js` signs in as `guest-booking@…`, books a room and cancels it in `afterAll`. - `e2e/account.test.js` signs in as a different user. On CI, the default reinstall means `account.test.js` never sees the booking session left by `booking.test.js`. Run locally with `--reuse` and the order can change what each file sees — acceptable while writing a test, not for the pipeline. ## Diagnosing a suspected state leak 1. Run the failing file **alone** with the default reinstall. If it passes alone and fails in the full suite, another file is feeding it state. 2. Run the suite with `--reuse` locally and in a **different file order**; order-dependent results confirm a leak. 3. Look for **stored data the test assumes**: a signed-in session, a cached "recently viewed hotels" list, a feature flag persisted on disk. 4. Fix the dependency by making the file create its own state (sign in, seed data) rather than by forcing an order. ## Where `behavior` fits `--reuse` is the CLI form of `behavior.init.reinstallApp: false` in `.detoxrc.js`, which can also be set per configuration. Setting `behavior.launchApp` to `manual` (for debugging native code) also turns reinstall off by default. Keep such settings out of the configuration CI uses.

  • Does the per-file reinstall make tests within one file independent?
    No. It runs once when the file's worker starts, so all tests in the file share the installed app and its data. Each test still needs a known starting point — a reload or relaunch in `beforeEach` — and a data reset when it needs a fresh user.
  • Why can two booking files still collide on CI even with reinstall?
    Reinstalling clears the device, not the backend. If both files use the same guest account or try to book the same room on the same dates, they interfere on the server, especially with parallel workers. Give each file its own account and data.

saying these in an interview costs you the question

  • Detox reinstalls the app before every single test.
  • --reuse also clears the app's stored data.
  • Reinstall per file isolates the backend too.
  • --reuse is the recommended CI setting for speed.
  • --reuse picks up native changes without a reinstall.