Mobile test suites decay faster than backend ones. UI tests break on every redesign, device farms are slow and expensive, and the failure that reaches users is usually a device-specific rendering problem no test covered. The goal is not more coverage; it is coverage in the layers where it survives.
01Why mobile inverts the usual advice
On the backend, end-to-end tests are the expensive top of the pyramid. On mobile they are more expensive still: they need a booted simulator or a real device, they are timing-sensitive, and they break on cosmetic changes that did not alter behaviour.
The consequence is that teams either maintain a small suite properly or a large suite badly. A large flaky suite is worse than none, because it trains everyone to re-run failures until green, which is the same as having no gate at all.
Push logic out of the UI so it can be tested without one. Business rules, formatting, validation and state transitions in plain functions are fast and stable to test; the same logic embedded in a component requires a device to verify.
02What each layer should cover
Assign each layer a job and stop asking any layer to do another's.
| Layer | Covers | Keep it |
|---|---|---|
| Unit | Business logic, formatting, state transitions | Large and fast |
| Component | Rendering given props, interaction handlers | Moderate, no network |
| Integration | Screen plus data layer with a mocked API | Focused on real flows |
| End-to-end | Critical paths only: login, purchase, core task | Very small |
| Manual | Exploratory, device-specific rendering, accessibility | Scheduled, not ad hoc |
03Device matrix without the bill
Testing every device is not possible and not necessary. What matters is coverage of the variables that actually change behaviour: OS version, screen size class, and memory tier.
Pick a small matrix - the oldest OS you support, the newest, one small screen, one large, and one low-memory device. That set catches the overwhelming majority of device-specific failures at a fraction of the cost of a broad farm run.
Run it on release candidates and nightly, not on every commit. The feedback delay is acceptable because these failures are rarely introduced by a single commit in a way you could not find the next morning.
04What automation will not catch
Automated tests confirm that what you specified still works. They do not tell you the tap target is too small, the contrast fails in sunlight, the animation makes people nauseous, or the flow is confusing.
Budget real manual time for exploratory testing on physical devices, and specifically for accessibility with a screen reader on. Both are consistently the source of issues that automation reports as passing and users report as broken.
Topics
Priya Iyer
Staff Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer