Testování UI v mobilních aplikacích: co to je, typy a jak se provádí

Co je testování UI?

Testování UI je typ automatizované kontroly, při které testovací kód interaguje s grafickým rozhraním aplikace stejně, jako by to dělal skutečný uživatel. Test najde na obrazovce prvek — tlačítko, textové pole, seznam — provede na něm akci a zkontroluje očekávanou reakci rozhraní. Například po zadání nesprávného hesla UI test zkontroluje, zda se na obrazovce objevila chybová zpráva se správným textem.

Hlavní rozdíl mezi UI testy a jinými typy automatizace je v tom, že pracují prostřednictvím vrstvy Accessibility operačního systému, nikoli prostřednictvím interních API aplikace. To znamená, že UI testy vidí rozhraní přesně tak, jako uživatel a systém čtení obrazovky. Díky tomu UI testy kontrolují nejen funkčnost, ale i přístupnost prvků — soulad s požadavky WCAG.

Podle průzkumu JetBrains Developer Ecosystem 2023 používá 58% mobilních týmů UI testy ve svém CI/CD pipeline. Průměrné pokrytí UI testy v komerčních projektech je 30–40% obrazovek aplikace. Projekty s UI testy dostávají o 25% méně negativních recenzí v obchodech s aplikacemi souvisejících s pády rozhraní.

Čím se testování UI liší od jednotkového

Hlavní rozdíl mezi UI testy a jednotkovými testy je úroveň abstrakce. Jednotkové testy pracují s jednotlivými třídami a funkcemi, izolovanými od frameworku Android nebo iOS. Provádějí se na JVM (pro Android) bez spuštění emulátoru a trvají milisekundy. UI testy běží na skutečném zařízení nebo emulátoru, interagují se systémovými službami a vyžadují sekundy nebo minuty na jeden scénář.

Liší se také cílové publikum testů. UI testy kontrolují komplexní uživatelské scénáře — registraci, zadání objednávky, vyhledávání. Jednotkové testy pokrývají business logiku: výpočty, validaci, transformaci dat. UI test nekontroluje správnost výpočtu daně — kontroluje, zda je konečná částka zobrazena na obrazovce. Samotný výpočet je ověřen jednotkovým testem.

Podle Google Testing Blog (2020) by optimální poměr testů v projektu měl následovat pravidlo testovací pyramidy: 70% jednotkových testů, 20% integračních testů a 10% UI testů. Porušení tohoto poměru ve prospěch UI testů vede k prodloužení doby provádění a křehkosti testovací sady, protože UI testy jsou citlivé na změny v rozvržení obrazovek.

Frameworky pro testování UI

Pro Android je dominantním frameworkem Espresso — knihovna od Google zabudovaná do AndroidX Test. Espresso se automaticky synchronizuje s vláknem UI a čeká na dokončení animací a úloh na pozadí před provedením další kontroly. Pro Jetpack Compose se používá rozšíření Compose UI Test, které pracuje prostřednictvím sémantických uzlů místo tradičních identifikátorů zobrazení.

Pro iOS je hlavním nástrojem XCUITest, který je součástí Xcode. Testy se píší v Swift a používají identifikátory Accessibility pro nalezení prvků. XCUITest podporuje nahrávání testů pomocí funkce record a integraci s CI systémy přes xcodebuild. Pro multiplatformní projekty se používá Appium, založený na protokolu WebDriver, který umožňuje spouštět stejné testy na Android a iOS s minimálními změnami v kódu.

Espresso a Compose UI Test

Espresso pracuje s tradičním systémem View prostřednictvím onView a identifikátorů zdrojů id. Compose UI Test používá sémantickou vrstvu, což činí testy méně závislými na hierarchii zobrazení. Například hledání tlačítka v Espresso: onView(withId(R.id.submit)), v Compose: onNodeWithTag(„submit”). Compose testy automaticky zpracovávají rekompozici a nevyžadují explicitní čekání na nečinný stav.

XCUITest pro iOS

XCUITest používá XCUIApplication jako vstupní bod. Každý prvek rozhraní se hledá prostřednictvím vlastností Accessibility: accessibilityIdentifier pro programový přístup a accessibilityLabel pro VoiceOver. Framework podporuje nahrávání testů pomocí funkce record v Xcode — vývojář provádí akce na simulátoru a Xcode generuje testovací kód. Hotové testy se spouštějí přes xcodebuild test.

Multiplatformní řešení

Appium je založen na protokolu WebDriver a podporuje libovolný jazyk: Java, Python, JavaScript. Pro hledání prvků se používají strategie id, xpath, class name a accessibility id. Appium vyžaduje instalaci serveru a konfiguraci Desired Capabilities — platformName, deviceName, appPackage. Alternativou je Maestro, který používá YAML scénáře a nevyžaduje kompilaci testovacího kódu.

• Espresso — onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed()))
• XCUITest — app.buttons[„loginButton”].tap(); XCTAssertTrue(app.staticTexts[„welcome”].exists)
• Appium — driver.findElement(By.id(„com.example:id/button”)).click()
• Detox — framework od Wix pro React Native, synchronizující se s JS vláknem
• Maestro — moderní nástroj s YAML scénáři, nevyžadující psaní kódu

Ukázky kódu pro UI testy

Podívejme se na UI testy pro stejný scénář — přihlášení do aplikace — ve třech různých frameworkových: Espresso pro Android, XCUITest pro iOS a Appium pro multiplatformní přístup. Scénář: zadejte uživatelské jméno a heslo, stiskněte tlačítko přihlášení, zkontrolujte zobrazení uvítací zprávy.

Android: Espresso

Test v Espresso používá onView pro nalezení prvku podle identifikátoru a perform pro provedení akce. Metoda check s matcherem isDisplayed potvrzuje, že je prvek viditelný na obrazovce.

@RunWith(AndroidJUnit4::class)
class LoginUiTest {

    @Rule
    @JvmField
    val composeTestRule = createComposeRule()

    @Test
    fun login_withValidCredentials_showsWelcome() {
        composeTestRule
            .onNodeWithTag("emailField")
            .performTextInput("user@example.com")
        composeTestRule
            .onNodeWithTag("passwordField")
            .performTextInput("secret123")
        composeTestRule
            .onNodeWithTag("loginButton")
            .performClick()
        composeTestRule
            .onNodeWithText("Vítejte, Uživateli!")
            .assertIsDisplayed()
    }
}

iOS: XCUITest

XCUITest používá XCUIApplication pro přístup k prvkům rozhraní prostřednictvím identifikátorů Accessibility. Metody tap() a exists zajišťují interakci a kontrolu.

class LoginUITests: XCTestCase {
    let app = XCUIApplication()

    override func setUp() {
        continueAfterFailure = false
        app.launch()
    }

    func testLogin_withValidCredentials_showsWelcome() {
        app.textFields["emailField"].tap()
        app.textFields["emailField"].typeText("uzivatel@example.com")
        app.secureTextFields["passwordField"].tap()
        app.secureTextFields["passwordField"].typeText("tajne123")
        app.buttons["loginButton"].tap()
        XCTAssertTrue(app.staticTexts["Welcome, User!"].exists)
    }
}

Nejlepší postupy testování UI

První zásada — používejte identifikátory Accessibility místo textových štítků pro hledání prvků. Text tlačítka se může změnit při lokalizaci, zatímco identifikátor zůstane stabilní. V Android je to vlastnost contentDescription, v iOS — accessibilityIdentifier. Tento přístup činí testy nezávislými na jazyce rozhraní a snížuje náklady na údržbu při změně copywritingu.

Vyhýbejte se sleep() a pevným zpožděním — používejte vestavěné mechanizmy čekání frameworku. Espresso automaticky čeká na dokončení animací a úloh na pozadí. XCUITest poskytuje XCTAssertTrue s timeoutem. Explicitní pauzy zpomalují testy a činí je méně stabilními, zejména na pomalých zařízeních v CI prostředí.

Seskupujte testy podle kritičnosti: smoke testy (3–5 klíčových scénářů) se spouštějí při každém commitu, kompletní sada UI testů — před vydáním. Podle Google Testing Blog (2022) UI testy, které trvají déle než 30 minut v CI, snižují frekvenci spouštění o 40%, což snižuje jejich efektivitu jako nástroje pro včasnou detekci regresí.

Omezení UI testů a jak je obejít

UI testy mají řadu omezení. Citlivost na změny rozvržení: změna identifikátoru, hierarchie nebo typu prvku rozbije test i při nezměněné funkčnosti. Řešení — použití vzoru Page Object, který centralizuje selektery prvků v samostatných třídách. Při změně rozvržení se opraví jeden soubor Page Object, nikoli desítky testů.

Doba provádění: spuštění na skutečném zařízení nebo emulátoru trvá 10–50krát déle než jednotkový test. Řešení — paralelní spouštění UI testů na několika zařízeních prostřednictvím Firebase Test Lab nebo AWS Device Farm. Nestabilita (flakiness) — častý problém CI spuštění způsobený animacemi, síťovým zpožděním nebo stavem emulátoru. Pro boj s flakiness se používá automatický restart neúspěšných testů a analýza stability každého testovacího scénáře.