Espresso Awareness: UI-Tests in View-basierten Android-Apps

Wer eine gewachsene Android-App mit View-basiertem UI pflegt, kommt an Espresso nicht vorbei. Das offizielle UI-Testframework von Google ermöglicht zuverlässige Instrumentierungstests direkt auf echtem Gerät oder Emulator – und bleibt in Projekten, die noch keinen vollständigen Wechsel zu Jetpack Compose vollzogen haben, das wichtigste Werkzeug für automatisierte Oberflächentests.

Was ist das?

Espresso ist Googles offizielles Framework für UI-Instrumentierungstests in Android-Apps. Es greift direkt auf die View-Hierarchie zu und erlaubt es, Interaktionen wie Tippen, Wischen oder Texteingabe zu simulieren und anschließend den Zustand von Views zu prüfen.

Im Unterschied zu Screenshot- oder Monkey-Tests kennt Espresso die App-Interna: Es läuft im selben Prozess wie die App und kann deshalb synchron auf den UI-Thread zugreifen. Das unterscheidet es auch von UI Automator, der außerhalb des App-Prozesses arbeitet und damit geräteweite Aktionen ermöglicht, aber weniger Einblick in die App-Struktur hat.

Espresso ist Teil der AndroidX Test Library und wird über die Testregeln ActivityScenarioRule oder die veraltete ActivityTestRule eingebunden. Es richtet sich primär an View-basierte UIs – wer Composables testet, greift stattdessen zur Compose Testing API mit composeTestRule.

Wie funktioniert es?

Das Herzstück von Espresso ist sein Synchronisationsmechanismus. Bevor Espresso eine Aktion ausführt oder eine Assertion prüft, wartet es automatisch darauf, dass der UI-Thread frei ist, alle AsyncTask-Warteschlangen geleert sind und alle registrierten IdlingResources als „idle” signalisieren.

Dieser Automatismus verhindert Race Conditions, die bei manuellen Thread.sleep()-Aufrufen zwangsläufig entstehen. Tests werden dadurch deterministischer und sind weniger anfällig für Timing-Probleme.

Die drei Kernkonzepte

Ein Espresso-Test besteht immer aus denselben drei Bausteinen:

1. onView(ViewMatcher) – findet die gewünschte View in der Hierarchie.
2. perform(ViewAction) – führt eine Interaktion aus, zum Beispiel einen Klick oder eine Texteingabe.
3. check(ViewAssertion) – prüft den erwarteten Zustand der View.

onView(withId(R.id.username_input))
    .perform(typeText("alice"), closeSoftKeyboard())

onView(withId(R.id.login_button))
    .perform(click())

onView(withId(R.id.welcome_message))
    .check(matches(isDisplayed()))

Für Hintergrundoperationen, die nicht über AsyncTask laufen – etwa Kotlin-Coroutinen, Retrofit-Calls oder Room-Datenbankzugriffe – musst du eine IdlingResource implementieren und bei Espresso registrieren. Das teilt dem Framework mit, wann die App bereit für den nächsten Schritt ist.

val idlingResource = CountingIdlingResource("network_calls")
IdlingRegistry.getInstance().register(idlingResource)

// Vor dem Netzwerkaufruf:
idlingResource.increment()
// Nach Abschluss im Repository oder ViewModel:
idlingResource.decrement()

Die CountingIdlingResource aus dem Paket androidx.test.espresso.idling zählt laufende Operationen und signalisiert „idle”, sobald der Zähler null erreicht. Für Coroutinen gibt es außerdem die fertige Hilfsbibliothek androidx.test.espresso.idling:idling-concurrent.

In der Praxis

Ein typischer Login-Test

Angenommen, du pflegst eine View-basierte Login-Activity. Ein vollständiger Espresso-Test könnte so aussehen:

@RunWith(AndroidJUnit4::class)
class LoginActivityTest {

    @get:Rule
    val activityRule = ActivityScenarioRule(LoginActivity::class.java)

    @Test
    fun successfulLogin_showsWelcomeScreen() {
        onView(withId(R.id.username_input))
            .perform(typeText("alice"), closeSoftKeyboard())

        onView(withId(R.id.password_input))
            .perform(typeText("secret123"), closeSoftKeyboard())

        onView(withId(R.id.login_button))
            .perform(click())

        onView(withId(R.id.welcome_message))
            .check(matches(withText(containsString("Willkommen"))))
    }
}

Die häufigste Stolperfalle: fehlende IdlingResource

Viele Teams kämpfen mit flaky Tests – Tests, die manchmal bestehen und manchmal scheitern, ohne dass sich der Code geändert hat. Der häufigste Grund: Die App führt nach einem Klick eine asynchrone Operation aus, und Espresso prüft den UI-Zustand, bevor das Ergebnis angekommen ist.

Die Lösung ist niemals Thread.sleep(), sondern eine korrekt implementierte IdlingResource. Wer Retrofit mit OkHttp verwendet, kann auf die fertige Bibliothek okhttp3-idling-resource zurückgreifen. Diese hängt sich transparent in den OkHttp-Client ein und signalisiert idle, sobald alle laufenden HTTP-Calls abgeschlossen sind.

Legacy-Kontext: Wann lohnt Espresso noch?

In vollständig auf Compose migrierten Projekten löst die Compose Testing API Espresso ab. In der Praxis existieren jedoch viele hybride Apps oder rein View-basierte Legacy-Apps, die auf absehbare Zeit nicht migriert werden. Für diese Projekte bleibt Espresso die erste Wahl für UI-Tests.

Eine pragmatische Entscheidungsregel: Enthält eine Activity oder ein Fragment noch Views statt Composables, schreibst du Espresso-Tests dafür. Composables testest du mit composeTestRule. Mische die Frameworks nicht innerhalb desselben Tests – das führt zu schwer lesbarem Code und Synchronisationsproblemen, weil beide Frameworks unterschiedliche Threading-Garantien machen.

Fazit

Espresso ist mehr als ein historisches Überbleibsel: Es ist das produktionserprobte UI-Testframework für alle Android-Apps, die noch Views einsetzen, und die Grundlage für stabile, wartbare Testsuites in gewachsenen Projekten. Der eingebaute Synchronisationsmechanismus nimmt dir die gefährlichsten Timing-Probleme ab – vorausgesetzt, du registrierst eigene Hintergrundoperationen korrekt als IdlingResource. Schau dir jetzt den Login-Flow oder einen anderen kritischen User-Flow deiner App an: Schreibe einen Espresso-Test dafür, lass ihn im Emulator laufen, und beobachte, ob er stabil grün bleibt oder flaky ist. Wenn er flaky ist, ist eine fehlende IdlingResource der wahrscheinlichste Schuldige – und das Debuggen dieser Ursache ist eine der lehrreichsten Übungen im Android-Testing.