Android Developer interview question
What is your Android testing strategy?
Test Android logic on the JVM where possible, use Compose or instrumentation tests for platform interaction, isolate repositories, control dispatchers and clocks, and keep a small end-to-end set for critical journeys.
Direct answer
What a strong answer covers
How it works
The pyramid is shaped by how slow the Android emulator is. Domain logic, ViewModels, and repositories run as plain JVM tests with fake data sources, a test dispatcher via runTest, and a controllable clock. Compose UI tests run either on the JVM with Robolectric or on device with the Compose test rule, asserting through semantics rather than view IDs. Room queries get tested against an in-memory database. A small end-to-end suite on real devices or an emulator farm covers login, the primary purchase or creation flow, and any notification-driven path.
Example
The login ViewModel is tested on the JVM with a fake AuthRepository returning success and failure, advancing the test scheduler to assert loading and error states. A Compose test renders the login screen with a fake ViewModel and checks that the button is disabled until both fields are filled. One instrumented test signs in against a staging backend on a device in CI nightly.
Common mistakes
- Testing ViewModels with Dispatchers.Main directly and getting flaky results from real threading.
- Writing every test as an instrumented test and waiting an hour for CI.
- Asserting on layout internals such as child indices instead of semantics users perceive.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.