Mobile Testing
Android has two official UI testing frameworks: Espresso and UI Automator. Teams new to Android testing often ask which to use. The answer is usually "both" — they serve different purposes and the distinction matters more than the choice. The Core Difference Espresso runs in the same process as
Mobile Testing
Beyond basic clicks and text input, Espresso supports complex UI interactions through custom ViewActions, the Intents API, WebView testing, and accessibility actions. This guide covers the advanced interaction patterns you'll need for real-world Android test suites. Custom ViewActions When built-in actions aren't enough, implement
Mobile Testing
Espresso's automatic synchronization is its killer feature: tests wait automatically until the main thread is idle before performing actions. But when your app does work on background threads — network calls, database operations, coroutines — Espresso doesn't automatically know when that work is done. IdlingResource solves this. How
Mobile Testing
Espresso's built-in matchers cover most cases, but real Android apps have custom views, complex states, and domain-specific conditions that built-in matchers can't express. Custom matchers let you write tests that read like specifications: onView(withProductName("Widget")) instead of onView(allOf(isDescendantOfA(
Mobile Testing
Espresso is Google's official Android UI testing framework. It's built into the Android Testing Support Library, runs directly on the device or emulator, and provides a concise API for interacting with and asserting on your app's UI. Unlike Appium or UiAutomator that use external
Testing
The Android testing community has been arguing about Robolectric vs Espresso for years. The argument is usually framed as a choice, when the reality is that they solve different problems and the interesting question is how to deploy both of them effectively. Let's be concrete about what each
Mobile Testing
Mobile teams constantly fight the same battle: test code for iOS and Android is 80% identical but diverges on selectors, gestures, permission dialogs, and platform-specific behaviors. The naive approach is two separate test suites. The right approach is shared test logic with platform adapters. This guide covers the architectural
Testing
Appium is the de facto standard for cross-platform mobile automation, and for Android it sits on top of UIAutomator2 — Google's own UI testing framework.
Testing
Unit tests on Android have a reputation for being awkward. Some of that is earned — the platform is deeply tied to Android SDK classes that require a device or Robolectric to instantiate. But most Android logic that matters can be tested in pure JVM unit tests if you structure the
Testing
Android instrumentation tests run on a real device or emulator. That means every test suite invocation involves booting an emulator, installing an APK, and waiting for the Android runtime to execute your code. A test suite that takes 20 seconds on a laptop can take 10 minutes in CI. Robolectric
Testing
Getting Android tests running in GitHub Actions is straightforward. Getting them running fast and reliably is not.
Kotlin
Unit tests tell you your logic is correct. Espresso tests tell you your UI actually works on a real Android device.