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. The architecture is layered: your test code talks to an Appium server over HTTP (WebDriver protocol), the server talks to UIAutomator2 running on
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. The emulator is the bottleneck: it's a full Android system image running in a VM, inside a GitHub Actions runner. There's overhead at every layer. This guide covers a
Kotlin
Espresso is Android's UI testing framework, executing tests directly on a device or emulator. This guide covers the full Espresso toolkit: ViewMatchers for finding views, ViewActions for interacting, ViewAssertions for validating state, IdlingResources for async synchronization, and Hilt for injecting test dependencies. Unit tests tell you your logic
Testing
Testing WearOS apps is different from phone testing. The screen is tiny, the interaction model is rotary input + swipe, and users expect extremely fast interactions — anything that takes more than 300ms feels slow on a watch. Horologist is Google's library for building and testing WearOS apps correctly. WearOS
Testing
Kaspresso is an Android UI test framework built on top of Espresso and UIAutomator. It solves the two biggest problems with raw Espresso: flaky tests and unreadable test code. With Kaspresso, you get a clean Kotlin DSL (via Kakao), automatic waiting and retry logic, and first-class Allure report integration.
Testing
Jetpack Compose has its own testing APIs that don't use Espresso's view matchers. Instead, Compose tests work against the semantics tree — an accessibility-oriented representation of your UI that's separate from the rendering layer. This makes Compose tests faster and less brittle than Espresso
Testing
Robolectric runs Android tests on the JVM — no emulator, no device, no waiting for adb to connect. It implements Android's framework classes as JVM-compatible stubs, so your Activities, Fragments, ViewModels, and Repositories run in a regular JUnit test process. A Robolectric test suite that takes 30 seconds
Testing
App performance isn't tested — it's measured. Android's Macrobenchmark library gives you a framework for measuring startup time, frame rendering, and custom interactions on real devices. Baseline Profiles use those measurements to pre-compile critical code paths, and Perfetto lets you trace exactly what'
Maestro
Maestro is a mobile testing framework that replaces imperative test code with declarative YAML flows. You describe what the user does — tap this, type that, assert visible — and Maestro handles synchronization, retries, and cross-platform execution. This guide covers the flow syntax, handling dynamic content, CI integration, and how Maestro