Testing and CI for Android Engineers (2026)

Unit testing modern Android: JUnit5 + Mockk + Turbine

The unit-test layer is where 70-80% of an Android codebase's tests should live: pure JVM, no Android framework dependencies, runs in milliseconds. The canonical 2026 stack is JUnit5 (Jupiter) for the runtime, Mockk for mocking, Turbine for Flow assertions, Truth or AssertK for fluent matchers, and kotlinx-coroutines-test for deterministic virtual time. The official Android testing fundamentals page (developer.android.com/training/testing) covers the Gradle wiring; everything below assumes AGP 8.x with the JUnit5 plugin applied.

JUnit5 over JUnit4 buys you parameterized tests without external libraries, lifecycle extensions (instead of fragile @Rule chains), nested test classes for grouping setup, and dynamic tests for table-driven cases. The migration cost is small — most JUnit4 tests work with @Rule converted to @ExtendWith — and the readability win is large.

Mockk (github.com/mockk/mockk) is the canonical Kotlin mocking library. It mocks final classes (which Mockito requires opt-in for), supports object/static mocking, and has first-class coroutine support via coEvery/coVerify. Relaxed mocks (mockk(relaxed = true)) return sensible defaults for unstubbed calls so tests stay focused on the behavior under test. The verbose Mockito-Kotlin alternative is acceptable but Mockk is the senior default.

Turbine (github.com/cashapp/turbine) is the canonical way to test Kotlin Flows. The pattern flow.test { awaitItem(); awaitComplete() } gives you a sequential, deterministic API that replaces flaky collectAsState-with-delay patterns. Pair Turbine with runTest from kotlinx-coroutines-test to get virtual time control: advanceTimeBy and advanceUntilIdle let you fast-forward without real-clock waits.

A canonical ViewModel test exercising all four libraries — JUnit5, Mockk, Turbine, runTest — looks like this:

@ExtendWith(MainDispatcherExtension::class)
class JobListViewModelTest {

    private val repo: JobRepository = mockk()
    private lateinit var vm: JobListViewModel

    @BeforeEach fun setUp() {
        vm = JobListViewModel(repo)
    }

    @Test fun `loads jobs and emits Success state`() = runTest {
        coEvery { repo.fetchJobs("android") } returns listOf(Job("1", "Sr Android"))

        vm.uiState.test {
            assertThat(awaitItem()).isEqualTo(JobUiState.Idle)
            vm.search("android")
            assertThat(awaitItem()).isEqualTo(JobUiState.Loading)
            val success = awaitItem() as JobUiState.Success
            assertThat(success.jobs).hasSize(1)
            cancelAndIgnoreRemainingEvents()
        }
        coVerify(exactly = 1) { repo.fetchJobs("android") }
    }
}

What this test gets right: MainDispatcherExtension swaps Dispatchers.Main for a TestDispatcher so viewModelScope runs deterministically; coEvery stubs the suspend function without ceremony; Turbine's test { } block makes Flow emissions sequential and assertable; coVerify confirms the repository was called exactly once with the expected argument; cancelAndIgnoreRemainingEvents prevents the test from hanging on an open Flow. The whole suite runs in milliseconds on the JVM with zero Android framework dependencies — the cheapest, fastest feedback you can give an Android engineer.

Compose UI testing: createComposeRule + semantics

Compose UI testing replaces the Espresso ViewMatchers world with a semantics-tree query API. Instead of finding views by ID and asserting on widget state, you query the merged semantics tree (the same one TalkBack uses) and assert on what the user can perceive. The canonical reference is developer.android.com/jetpack/compose/testing, which documents the full createComposeRule API, semantics matchers, and synchronization model.

There are two test-rule factories. createComposeRule() is for tests of pure Composables with no Activity dependency — the fastest path, runs under Robolectric or on-device. createAndroidComposeRule<ActivityT>() is for tests that need a real Activity (system intents, Activity-scoped DI, Activity result contracts). Default to createComposeRule; reach for the Activity variant only when the test genuinely depends on the Activity lifecycle.

The query API has three primary entry points: onNodeWithText (matches displayed text), onNodeWithTag (matches Modifier.testTag), and onNodeWithContentDescription (matches accessibility labels). Test tags are the senior pattern for testing — they're explicit, stable, and don't break when copy changes. The rule against testing internal implementation: never assert on Composable internals like raw padding values; always assert on what a user (or accessibility service) would perceive.

Synchronization is automatic. The compose rule waits for the recomposition queue and animation clock to be idle before each assertion. When you need to control time explicitly — testing a debounced search field, a fade-in animation — use composeTestRule.mainClock.autoAdvance = false plus mainClock.advanceTimeBy(millis). This gives you the same virtual-time pattern as kotlinx-coroutines-test, but for the Compose frame clock.

A canonical Compose UI test exercising createComposeRule and the semantics API:

class LoginScreenTest {
    @get:Rule val rule = createComposeRule()

    @Test fun `submit button enables when email and password are valid`() {
        rule.setContent { LoginScreen(onSubmit = {}) }

        rule.onNodeWithTag("submit").assertIsNotEnabled()
        rule.onNodeWithTag("email").performTextInput("[email protected]")
        rule.onNodeWithTag("password").performTextInput("hunter2!")
        rule.onNodeWithTag("submit")
            .assertIsEnabled()
            .assertHasClickAction()
            .performClick()
    }
}

What this test gets right: tags on the testable affordances (Modifier.testTag("submit")) instead of brittle text matching; assertions chained on the same node for readability; explicit pre/post state assertions that document the contract; performClick exercises the full Modifier.clickable path including ripple and accessibility announcements.

For the testTag pattern to work, the production Composable needs Modifier.semantics { testTagsAsResourceId = true } at a parent boundary if you want Espresso/UIAutomator interop, or simply Modifier.testTag("submit") on the leaf for Compose-only tests. The Android docs cover both patterns in the testing guide linked above.

Screenshot testing: Paparazzi + Roborazzi

Screenshot testing catches visual regressions that no semantic test can: a misplaced padding, a wrong dark-theme color, a text-overflow ellipsis. In 2026 the Android ecosystem has two production-ready options, and serious teams use both for different layers of the pyramid.

Paparazzi (github.com/cashapp/paparazzi) is Cash App's pure-JVM Compose/View renderer built on LayoutLib (the same renderer Android Studio's preview pane uses). It runs as a JUnit rule on the JVM with no emulator, no Robolectric, no instrumentation. A single Paparazzi test renders in 50-200ms; a 500-test suite runs in under a minute. The trade-off: LayoutLib doesn't run animations or process input; Paparazzi snapshots a single frame.

The Paparazzi pattern: declare @get:Rule val paparazzi = Paparazzi(...), then in each @Test call paparazzi.snapshot { MyComposable() }. The first run writes baseline PNGs to src/test/snapshots/; subsequent runs compare and fail on diff above a configurable threshold. CI uploads the diff PNGs as artifacts so reviewers can see exactly what changed.

Roborazzi (github.com/takahirom/roborazzi) takes a different approach: it hooks into Robolectric's rendering pipeline and lets you snapshot a Compose tree at any point during a Robolectric test. This means Roborazzi can capture animations mid-frame, post-input states, gesture-driven UI, and anything else that requires the full Android runtime. The cost is speed (Robolectric setup is heavier than Paparazzi) and occasional shadow-class quirks.

The senior pattern in 2026: Paparazzi for the static design-system layer (every reusable component, every theme, every locale variant); Roborazzi for the interactive layer (post-tap states, scroll positions, animation midpoints). Both render to PNG, both diff against baselines, both gate the merge on visual approval.

Baseline management is the operational reality of screenshot tests. The canonical workflow: developer runs ./gradlew recordPaparazziDebug locally to update baselines, commits them in the same PR as the code change, reviewer compares the baseline diff in GitHub. Storing PNGs in git is fine for typical Compose components (4-40 KB each); repos with thousands of snapshots use Git LFS.

Flakiness is the failure mode to design against. Common sources: system fonts (pin via Paparazzi.deviceConfig with a known font), date/time-dependent UI (inject a Clock and pass a fixed instant), random IDs (seed any RNG in your design system), and dark-mode animations (snapshot the steady state, not the transition). The teams that succeed with screenshot testing treat determinism as a first-class API contract, not an afterthought.

CI on GitHub Actions: matrix builds + Firebase Test Lab

The 2026 senior CI pipeline for Android has two tiers. Tier 1 (every PR) runs on GitHub Actions ubuntu-latest with no emulator: unit tests (JUnit5), Robolectric tests, Paparazzi/Roborazzi screenshots, ktlint/detekt, and a release build. The whole tier 1 should finish in under 10 minutes on a properly cached pipeline. Tier 2 (nightly + release branches) runs instrumented Espresso/UI Automator tests on Firebase Test Lab against a curated device matrix: pixel 7/8/9 on API 30/33/35, plus one low-end and one tablet. The split keeps PR feedback fast while still catching device-specific regressions before release.

The Gradle cache is the single biggest CI win. actions/cache for ~/.gradle/caches and ~/.gradle/wrapper, keyed on the hash of *.gradle*, gradle-wrapper.properties, and gradle/libs.versions.toml, takes a cold build from 8 minutes to under 2. The Gradle build-cache (--build-cache plus a remote node like develocity) further cuts incremental work.

For PRs that genuinely need an emulator (deep-link intent tests, system-UI permission flows), reactivecircus/android-emulator-runner is the canonical action. It boots an AVD with hardware acceleration on Linux runners (KVM available on ubuntu-latest since late 2023) and caches the AVD snapshot so subsequent runs skip the cold boot. Without snapshot caching, AVD boot is 2-3 minutes; with it, 20-30 seconds.

Firebase Test Lab (firebase.google.com/docs/test-lab) is the senior choice for nightly/release-tier coverage. It runs your instrumented APK + test APK on real and virtual devices in Google's data center, captures logcat, video, and screenshots, and surfaces the results via gcloud or the Firebase console. The pricing model (per-device-minute) makes it impractical to run on every PR for a large suite, but it's the right tool for release gating against the device matrix you actually ship to.

A canonical GitHub Actions workflow for tier 1 covers checkout, JDK setup, Gradle cache, and the test matrix:

name: Android CI
on: [pull_request, push]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        api-level: [30, 33, 35]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with: { distribution: temurin, java-version: 21 }
      - uses: gradle/actions/setup-gradle@v3
        with: { cache-read-only: ${{ github.ref != 'refs/heads/main' }} }
      - run: ./gradlew testDebugUnitTest --stacktrace
      - run: ./gradlew verifyPaparazziDebug
      - run: ./gradlew :app:roborazziDebug
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: screenshot-diffs-${{ matrix.api-level }}
          path: '**/build/paparazzi/failures/**'

What this workflow gets right: JDK 21 (the AGP 8.x baseline), gradle/actions/setup-gradle (handles caches and dependency-graph submission), conditional cache-read-only so only main branch writes the cache (avoids cache poisoning from PRs), explicit screenshot-diff artifact upload on failure, and a matrix on api-level so test code that branches on Build.VERSION.SDK_INT is exercised against each.

What this workflow does NOT include: the Test Lab tier 2 (a separate workflow on a schedule trigger using google-github-actions/auth and gcloud firebase test android run), retry-on-flake (use --rerun-tasks sparingly; flaky tests should be quarantined and fixed, not papered over), and SonarQube/Codecov upload (additive, not load-bearing). The senior+ implementation composes all of these but keeps the PR-tier surface minimal so feedback stays fast.

Bitrise is the alternative platform for Android CI in 2026. Its strengths are managed macOS for iOS+Android orgs, a step library with first-party Android steps, and Apple-Google chain-of-trust signing. The trade-off versus GitHub Actions: vendor lock-in on the workflow YAML format and per-build-minute pricing that gets expensive at scale. For Android-only orgs already on GitHub, GHA is the default; for orgs with deep iOS investment, Bitrise pays back the lock-in cost.