Mobile Testing
Instrumentation test
Also known as: instrumented test, androidTest
An instrumentation test is an Android test that runs on a device or emulator with access to the real Android framework, as opposed to a local unit test that runs on the JVM of the build machine.
Android splits tests by where they execute. Local unit tests live in `test/` and run on the host JVM in milliseconds, but see only stubbed Android APIs. Instrumentation tests live in `androidTest/`, are packaged into a second APK, and run on a real device or emulator through an instrumentation runner — so they can touch the actual framework, real lifecycle callbacks and real UI. Espresso and UI Automator tests are instrumentation tests.
The trade-off is speed and stability. Instrumentation tests are orders of magnitude slower than JVM tests and inherit every environmental variable of the device they run on — animation state, available memory, permission dialogs, emulator contention in CI. That is why they are the usual home of Android flakiness, and why teams push assertions down to local unit tests wherever the Android framework is not genuinely part of what is being tested.
- Runs on a device or emulator; local unit tests run on the host JVM.
- Espresso and UI Automator tests are instrumentation tests.
- Slower and far more flake-prone — keep only what genuinely needs the framework.
Learn more
Related terms
See it in your own test results
Qualflare detects flaky tests, clusters failures by root cause, and scores release risk from the test results you already produce in CI. Start free.
Start free with Qualflare← Back to the testing & observability glossary.
Last reviewed September 10, 2026