Espresso — was es ist, Funktionsprinzipien und wie man es verwendet

Was ist Espresso?

Espresso ist eine Bibliothek zum Schreiben automatisierter UI-Tests für Android, Teil von Google AndroidX Test. Sie bietet eine API zum Auffinden von View-Elementen auf dem Bildschirm, zum Ausführen von Aktionen (Klicken, Eingeben, Wischen) und zum Überprüfen ihres Zustands (angezeigt, enthält Text, aktiviert).

Die Hauptfunktion von Espresso ist die automatische Synchronisierung mit dem Hauptthread der Anwendung. Das Framework wartet auf den Abschluss aller asynchronen Tasks (Coroutinen, AsyncTask, Handler), bevor es die nächste Prüfung durchführt. Dadurch werden flakige Tests durch Wettlaufsituationen vermieden und UI-Tests werden stabil und zuverlässig — kein Test enthält Thread.sleep() oder Warteschleifen.

Espresso folgt dem Prinzip des Dreibeinigen Hundes — ein Test besteht aus drei Schritten: Element finden (ViewMatcher), Aktion ausführen (ViewAction), Ergebnis überprüfen (ViewAssertion). Alle drei Schritte werden in einer Aufrufkette geschrieben: onView().perform().check(). Dieses Konzept macht Tests vorhersagbar und leicht lesbar — jeder Test beschreibt explizit, wonach er sucht, was er tut und was er prüft.

Wie Espresso funktioniert

Architektur von Espresso basiert auf drei Komponenten: Espresso (Einstiegspunkt — statische Methoden onView und onData), ViewMatchers (Elementsuche), ViewActions (Aktionen) und ViewAssertions (Prüfungen). Intern verwendet das Framework Idling Resource zur Synchronisierung mit dem UI-Thread.

Einfacher Espresso-Test

Der einfachste Test findet eine Schaltfläche anhand der ID, führt einen Klick aus und überprüft, ob der Text „Erledigt“ erscheint. Aus Sicht des Tests sind alle Operationen synchron — Espresso garantiert, dass der UI-Thread die Ereignisverarbeitung abgeschlossen hat, bevor der Test fortgesetzt wird. Dies wird durch einen integrierten Wartemechanismus erreicht: onView blockiert die Testausführung, bis die UI im Leerlauf ist.

@Test
fun buttonClick_showsSuccessText() {
    // Schaltfläche anhand der ID finden und klicken
    onView(withId(R.id.button_submit))
        .perform(click())

    // Überprüfen, dass der Text „Erledigt“ angezeigt wird
    onView(withText("Erledigt"))
        .check(matches(isDisplayed()))
}

ActivityScenario-Regel

Zum Starten eines Espresso-Tests wird ActivityScenario (AndroidX Test) verwendet, das eine Activity in einem bestimmten Zustand erstellt — laufend, pausiert oder zerstört. ActivityScenario ermöglicht das Testen des Activity-Lebenszyklus zusätzlich zu reinen UI-Tests. Beispielsweise kann überprüft werden, ob Daten bei Bildschirmdrehung (Activity-Neuerstellung) erhalten bleiben und nach der Zerstörung wiederhergestellt werden.

ViewMatchers: UI-Elemente finden

ViewMatchers ist eine Sammlung von Methoden der Klasse Espresso.onView, die es ermöglichen, Views auf dem Bildschirm nach verschiedenen Kriterien zu finden: Ressourcen-ID (R.id), Text, Hinweis, übergeordnetes Element und Hierarchie. Wenn ein Matcher kein eindeutiges Ergebnis liefert, können Matcher mit allOf() kombiniert werden.

Kombination von Matchern

Wenn mehrere identische Elemente auf dem Bildschirm vorhanden sind (z. B. zwei TextViews mit unterschiedlichem Text), ist es praktisch, Matcher mit allOf zu kombinieren: onView(allOf(withId(R.id.title), withText(„Hallo“))). Dies garantiert die Auswahl eines einzelnen Elements. Der inverse Operator — not() — schließt Elemente von der Suche aus, und hasSibling() findet ein Element neben einem bekannten.

ViewActions: Interaktion mit der UI

ViewActions sind Aktionen, die Espresso auf der gefundenen View ausführt: click(), typeText(), clearText(), scrollTo(), swipeLeft() und andere. Aktionen werden an die Methode perform() übergeben, die mehrere Aktionen nacheinander akzeptieren kann.

Aktionsverkettung

Die Methode perform() akzeptiert vararg ViewAction und ermöglicht so die Ausführung einer Sequenz von Aktionen auf einem Element: Feld löschen, neuen Text eingeben, Tastatur schließen und Schaltfläche klicken. Alle Aktionen werden in der angegebenen Reihenfolge ausgeführt, und Espresso garantiert, dass die vorherige Aktion abgeschlossen ist, bevor die nächste beginnt.

// Text in EditText eingeben und Schaltfläche klicken
onView(withId(R.id.edit_email))
    .perform(
        clearText(),
        typeText("user@example.com"),
        closeSoftKeyboard()
    )

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

Überprüfung via onData

Für Elemente innerhalb von AdapterView (ListView, RecyclerView) wird die Methode onData() anstelle von onView verwendet. Sie arbeitet mit Adapterdaten statt mit Views — findet ein Element anhand des Modellinhalts und gibt die entsprechende View für weitere Aktionen zurück. onData verwendet Hamcrest-Matcher, um ein Element anhand von Modelldatenfeldern zu lokalisieren.

ViewAssertions: Zustandsprüfung

ViewAssertions überprüfen, ob sich eine View in einem bestimmten Zustand befindet. Die grundlegende Methode — matches(matcher) — prüft, ob das Element mit dem angegebenen Matcher übereinstimmt. Zusätzlich bietet Espresso doesNotExist() (Element fehlt) und selectedDescendantsMatch() (Prüfung verschachtelter Elemente).

Typische Prüfungen

Die häufigsten Prüfungen in UI-Tests: Element wird angezeigt (isDisplayed), Element enthält bestimmten Text (withText), Element ist aktiviert (isEnabled), Element ist nicht ausgewählt (isNotChecked). Jede Prüfung wirft bei Fehlschlag eine detaillierte Ausnahme — einschließlich der View-Hierarchie auf dem Bildschirm. Dies vereinfacht das Debugging: Die Fehlermeldung zeigt, welche Elemente zum Zeitpunkt der Prüfung tatsächlich auf dem Bildschirm waren.

Benutzerdefinierte ViewAssertions

Wenn Standardprüfungen nicht ausreichen, kann eine eigene über das Interface ViewAssertion erstellt werden. Eine benutzerdefinierte Assertion erhält eine View und kann deren Zustand programmatisch prüfen — beispielsweise Textfarbe, Abstände oder den Zustand einer benutzerdefinierten Komponente, die nicht über Standard-Matcher verfügbar ist.

// Prüfung: TextView wird angezeigt und enthält Text
onView(withId(R.id.text_welcome))
    .check(matches(isDisplayed()))
    .check(matches(withText("Willkommen")))

// Prüfung: Element wird NICHT angezeigt
onView(withId(R.id.progress_bar))
    .check(doesNotExist())

Idling Resources für asynchrone Operationen

Idling Resource ist der Mechanismus von Espresso zur Synchronisierung des Tests mit asynchronen Operationen. Standardmäßig wartet Espresso auf Handler, AsyncTask und Coroutinen (über coroutinesIdlingResource). Wenn die Anwendung Hintergrundarbeit über benutzerdefinierte Threads oder Callback-Dienste ausführt, muss eine benutzerdefinierte Idling Resource registriert werden.

Beispiel mit Coroutinen

Ab AndroidX Test 1.4.0 unterstützt Espresso Coroutinen über CoroutinesIdlingResource. Der Test wartet automatisch auf den Abschluss aller gestarteten Coroutinen, bevor UI-Prüfungen durchgeführt werden. Für komplexere Szenarien wird CountingIdlingResource verwendet — ein Zähler, der bei Taskstart inkrementiert und bei Abschluss dekrementiert wird.

// IdlingResource für OkHttp registrieren
class OkHttpIdlingResource(
    private val client: OkHttpClient
) : IdlingResource {

    private var isIdle = true
    private var watcher: IdlingResource.ResourceCallback? = null

    override fun getName() = "OkHttp"

    override fun isIdleNow() = isIdle

    override fun registerIdleTransitionCallback(
        callback: IdlingResource.ResourceCallback
    ) {
        watcher = callback
    }
}

Espresso im Android-Projekt einrichten

Einbindung von Espresso in ein Android-Projekt erfolgt durch Hinzufügen von Abhängigkeiten zur build.gradle auf Modulebene. Espresso ist Teil von AndroidX Test, daher reicht es, Abhängigkeiten für den Espresso-Kern, Erweiterungen und die JUnit-Integration anzugeben. Tests werden im Verzeichnis src/androidTest abgelegt und auf einem physischen Gerät oder Emulator über AndroidJUnitRunner ausgeführt.

Gradle-Konfiguration

Der minimale Abhängigkeitssatz umfasst espresso-core (Kern), espresso-contrib (zusätzliche Matcher für RecyclerView, Drawer, Picker) und runner (AndroidX-Test-Runner). Alle Tests werden auf einem Emulator oder physischen Gerät über Android Test Orchestrator ausgeführt.

// build.gradle.kts (androidTest-Abhängigkeiten)
android {
    defaultConfig {
        testInstrumentationRunner =
            "androidx.test.runner.AndroidJUnitRunner"
    }
}

dependencies {
    androidTestImplementation("androidx.test.espresso:espresso-core:3.6.1")
    androidTestImplementation("androidx.test.espresso:espresso-contrib:3.6.1")
    androidTestImplementation("androidx.test:runner:1.6.1")
    androidTestImplementation("androidx.test:rules:1.6.1")
}

Testausführung auf CI

Espresso-Tests können über Google Android Test Orchestrator ausgeführt werden, der jeden Test in einem separaten Prozess isoliert und den Zustand zwischen den Läufen bereinigt. Dadurch werden flakige Tests durch Restdaten vorheriger Tests vermieden und die Stabilität auf CI-Servern verbessert. Für die parallele Ausführung wird Sharding verwendet — Verteilung der Tests auf mehrere Emulatoren.