A Detox test in a lottery app hangs after launch because a 'drawing numbers' loader animates endlessly; how do you diagnose and fix it?

## Why the test hangs **Detox** runs every action and expectation only after the app is idle, and running animations count as busy. An `Animated.loop` spinner, a looping illustration or an animated GIF that never stops therefore means the app is **never** idle. The step waits until a timeout fails the test, often after a long pause that looks like a frozen run. This strictness is intentional. It often exposes a real bug, but not always, so the job is to find out which case you are in. ## Step 1: find the busy resource Detox's **synchronization debugging** is on by default. When an action or expectation takes longer than `session.debugSynchronization` (10 000 ms by default), Detox queries the app and logs what keeps it busy: ```text The app is busy with the following tasks: • UI elements are busy: - View animations pending: 2. - Layers pending animations: 7. • 1 enqueued native timers: ... ``` You can lower the threshold for a debugging run with `detox test --debug-synchronization 5000`, or set it in the config. The iOS and Android logs look different but name equivalent resources. On iOS, the launch arguments `DTXEnableVerboseSyncSystem` and `DTXEnableVerboseSyncResources` produce even more detail in the system log. ## Step 2: is it a bug? In the lottery app, the "drawing numbers" loader should be replaced by the results once the draw request returns. If it keeps spinning, check these in order: 1. **The server never answers.** The busy log also lists the in-flight **network URLs**. Fix the endpoint, the test environment or the mock server. 2. **The server answered with an error the UI ignores.** No URLs are pending, but the loader stays. Look in the app/device logs, which Detox can record as artifacts, for the error and make the UI show a failure state. 3. **The app threw while handling valid data**, for example parsing the draw result. The error with its stack trace appears in the logs. In all three cases the right fix is in the app: the hang caught a stuck loader a real user would also see. ## Step 3: an animation that loops on purpose Some animations never end by design: an attract loop on the home screen, a shimmering jackpot banner. Detox has **no API to exclude animations** from synchronization (it does for network URLs), so the options are: - **Mock the component in the e2e build.** Detox mocking works through Metro, not `jest.mock`: add a file such as `JackpotBanner.e2e.tsx` that renders a static version, and put `e2e.tsx` in front of Metro's `resolver.sourceExts` when bundling the build under test. The app under test no longer animates; every other test keeps full synchronization. - **Disable synchronization around the affected steps.** `await device.disableSynchronization()`, then wait explicitly for the elements you need with `waitFor(element(...)).toBeVisible().withTimeout(...)`, and `await device.enableSynchronization()` once you are back on a screen that can go idle. Keep this region as small as possible; everything in it is exposed to timing again. - **Stop the animation when it is not visible.** A loop that keeps running after its screen is covered is also wasted CPU for real users. ## Step 4: hidden animations The worst cases are animations you cannot see: - a loader in a bottom tab that was mounted at launch but never visited; - a list row far below the fold with an animated badge; - a small spinner leaked underneath the header. Useful techniques, from the Detox troubleshooting guide: step through the test in debug mode and explore the app by hand until Detox unblocks; capture a view hierarchy at the stuck moment; use Android Studio's Layout Inspector; or remove chunks of the screen until the blockage disappears, then narrow down. ## What not to do | Tempting move | Why it is wrong | |---|---| | Add `sleep()` calls | the app still never idles; the next step blocks again | | Raise every timeout | the run just hangs longer before failing | | Disable synchronization for the whole suite | every test loses automatic waiting and becomes timing-dependent | | Blacklist URLs | the busy resource is an animation, not the network | ## Summary Read the busy log, treat a stuck loader as a probable app bug, and only for a deliberately endless animation reach for an e2e mock or a narrowly scoped `disableSynchronization()`.