Espresso — co to je, principy fungování a jak používat

Co je Espresso?

Espresso je knihovna pro psaní automatizovaných UI testů pro Android, která je součástí Google AndroidX Test. Poskytuje API pro vyhledávání View prvků na obrazovce, provádění akcí na nich (kliknutí, zadání, swipnutí) a kontrolu jejich stavu (zobrazuje se, obsahuje text, je aktivní).

Klíčovou vlastností Espressa je automatická synchronizace s hlavním vláknem aplikace. Framework čeká na dokončení všech asynchronních úkolů (corutiny, AsyncTask, Handler) před provedením další kontroly. To eliminuje flaky testy související s race condition a dělá UI testy stabilními a spolehlivými — žádný test neobsahuje Thread.sleep() nebo čekací smyčky.

Espresso následuje princip Three-Legged Dog — test se skládá ze tří kroků: najít prvek (ViewMatcher), provést akci (ViewAction), zkontrolovat výsledek (ViewAssertion). Všechny tři kroky se zapisují do řetězce volání onView().perform().check(). Tento koncept dělá testy předvídatelnými a snadno čitelnými — každý test jasně popisuje, co hledá, co dělá a co kontroluje.

Jak funguje Espresso

Architektura Espressa je založena na třech komponentách: Espresso (vstupní bod — statické metody onView a onData), ViewMatchers (vyhledávání prvků), ViewActions (akce) a ViewAssertions (kontroly). Uvnitř framework používá Idling Resource pro synchronizaci s UI vláknem.

Základní Espresso test

Nejjednodušší test najde tlačítko podle ID, provede kliknutí a zkontroluje, zda se objevil text „Hotovo“. Všechny operace se provádějí synchronně z pohledu testu — Espresso zaručuje, že UI vlákno dokončilo zpracování události dříve, než test pokračuje v provádění. Toho je dosaženo vestavěným mechanizmem čekání: onView blokuje provádění testu, dokud UI není stabilní.

@Test
fun buttonClick_showsSuccessText() {
    // Najít tlačítko podle ID a kliknout
    onView(withId(R.id.button_submit))
        .perform(click())

    // Zkontrolovat, že se text „Hotovo“ zobrazuje
    onView(withText("Hotovo"))
        .check(matches(isDisplayed()))
}

Pravidlo ActivityScenario

Pro spuštění Espresso testu se používá ActivityScenario (AndroidX Test), který vytváří Activity v požadovaném stavu — spuštěná, pozastavená, zničená. ActivityScenario umožňuje testování životního cyklu Activity vedle čistého UI. Například lze zkontrolovat, že data jsou uložena při otočení obrazovky (rekreace Activity) a obnovena po zničení.

ViewMatchers: vyhledávání UI prvků

ViewMatchers jsou sada metod ze třídy Espresso.onView, které umožňují najít View na obrazovce podle různých kritérií: identifikátoru zdroje (R.id), textu, hint nápovědy, rodičovského prvku a hierarchie. Pokud jeden matcher nedává jedinečný výsledek, matchery se kombinují prostřednictvím allOf().

Kombinace matcherů

Pokud je na obrazovce několik stejných prvků (například dva TextView s různým textem), je vhodné kombinovat matchery pomocí allOf: onView(allOf(withId(R.id.title), withText(„Ahoj“))). To zaručuje výběr jedinečného prvku. Opačný operátor — not() — vylučuje prvky z vyhledávání a hasSibling() hledá prvek vedle známého.

ViewActions: interakce s UI

ViewActions jsou akce, které Espresso provádí nad nalezeným View: click(), typeText(), clearText(), scrollTo(), swipeLeft() a další. Akce se předávají metodě perform(), která může přijmout několik akcí za sebou.

Řetězec akcí

Metoda perform() přijímá vararg ViewAction, což umožňuje provést sekvenci akcí nad jedním prvkem: vyčistit pole, zadat nový text, zavřít klávesnici a stisknout tlačítko. Všechny akce se provádějí v pořadí, v jakém jsou uvedeny, a Espresso zaručuje, že předchozí akce byla dokončena před zahájením následující.

// Zadání textu do EditTextu a stisknutí tlačítka
onView(withId(R.id.edit_email))
    .perform(
        clearText(),
        typeText("user@example.com"),
        closeSoftKeyboard()
    )

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

Kontrola pomocí onData

Pro prvky uvnitř AdapterView (ListView, RecyclerView) se místo onView používá metoda onData(). Pracuje s daty adaptéru, nikoli s View — najde prvek podle obsahu modelu a vrátí odpovídající View pro další akce. onData používá hamcrest matchery k nalezení prvku podle polí datového modelu.

ViewAssertions: kontrola stavu

ViewAssertions kontrolují, zda je View v určitém stavu. Základní metoda — matches(matcher) — kontroluje, zda prvek odpovídá zadanému matcheru. Doplňkově Espresso nabízí doesNotExist() (prvek neexistuje) a selectedDescendantsMatch() (kontrola vnořených prvků).

Typické kontroly

Nejčastější kontroly v UI testech: prvek se zobrazuje (isDisplayed), prvek obsahuje určitý text (withText), prvek je aktivní (isEnabled), prvek není vybrán (isNotChecked). Každá kontrola v případě neúspěchu vyhodí podrobnou výjimku — s uvedením hierarchie View na obrazovce. To zjednodušuje ladění: v chybové zprávě je vidět, které prvky byly skutečně na obrazovce v okamžiku kontroly.

Vlastní ViewAssertions

Pokud standardní kontroly nestačí, lze vytvořit vlastní pomocí rozhraní ViewAssertion. Vlastní assertion obdrží View a může kontrolovat jeho stav programově — například barvu textu, okraje nebo stav vlastní komponenty, která není vystavena prostřednictvím standardních matcherů.

// Kontrola: TextView se zobrazuje a obsahuje text
onView(withId(R.id.text_welcome))
    .check(matches(isDisplayed()))
    .check(matches(withText("Vítejte")))

// Kontrola: prvek se NEzobrazuje
onView(withId(R.id.progress_bar))
    .check(doesNotExist())

Idling Resources pro asynchronní operace

Idling Resource je mechanizmus Espressa pro synchronizaci testu s asynchronními operacemi. Ve výchozím nastavení Espresso čeká na dokončení Handler, AsyncTask a corutin (prostřednictvím coroutinesIdlingResource). Pokud aplikace provádí práci na pozadí prostřednictvím vlastních vláken nebo Callback služeb, je třeba zaregistrovat vlastní Idling Resource.

Příklad s corutinami

Od AndroidX Test 1.4.0 Espresso podporuje corutiny pomocí CoroutinesIdlingResource. Test automaticky čeká na dokončení všech spuštěných corutin před provedením UI kontrol. Pro složitější scénáře se používá CountingIdlingResource — počítadlo, které se zvyšuje při zahájení úkolu a snižuje při dokončení.

// Registrace IdlingResource pro OkHttp
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
    }
}

Nastavení Espressa v Android projektu

Připojení Espressa v Android projektu se provádí přidáním závislostí do build.gradle na úrovni modulu. Espresso je součástí AndroidX Test, takže staāí uést závislosti pro jádro Espressa, rozšíření a JUnit integraci. Testy jsou umístěny v adresáři src/androidTest a spouštějí se na fyzickém zařízení nebo emulátoru pomocí AndroidJUnitRunner.

Konfigurace Gradle

Minimální sada závislostí zahrnuje espresso-core (jádro), espresso-contrib (další matchery pro RecyclerView, Drawer, Picker) a runner (testovací runner AndroidX). Všechny testy se spouštějí na emulátoru nebo fyzickém zařízení pomocí Android Test Orchestrator.

// build.gradle.kts (androidTest dependencies)
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")
}

Spouštění testů na CI

Espresso testy lze spouštět pomocí Google Android Test Orchestrator, který izoluje každý test v samostatném procesu a čistí stav mezi spuštěními. To eliminuje flaky testy související se zbytkovými daty předchozích testů a zvyšuje stabilitu na CI serverech. Pro paralelní spouštění se používá sharding — rozdělení testů mezi více emulátorů.