Testowanie UI w aplikacjach mobilnych: co to jest, rodzaje i jak się przeprowadza

Co to jest testowanie UI?

Testowanie UI to rodzaj zautomatyzowanego sprawdzania, w którym kod testowy współdziała z graficznym interfejsem aplikacji tak samo, jak robiłby to prawdziwy użytkownik. Test znajduje na ekranie element — przycisk, pole tekstowe, listę — wykonuje na nim działanie i sprawdza oczekiwaną reakcję interfejsu. Na przykład po wprowadzeniu nieprawidłowego hasła test UI sprawdza, czy na ekranie pojawił się komunikat o błędzie z poprawnym tekstem.

Główna różnica między testami UI a innymi rodzajami automatyzacji polega na tym, że działają one przez warstwę Accessibility systemu operacyjnego, a nie przez wewnętrzne API aplikacji. Oznacza to, że testy UI widzą interfejs dokładnie tak, jak użytkownik i system czytania ekranu. Dzięki temu testy UI sprawdzają nie tylko funkcjonalność, ale także dostępność elementów — zgodność z wymaganiami WCAG.

Według ankiety JetBrains Developer Ecosystem 2023, 58% zespołów mobilnych używa testów UI w swoim pipeline CI/CD. Średnie pokrycie testami UI w projektach komercyjnych wynosi 30–40% ekranów aplikacji. Projekty z testami UI o 25% rzadziej otrzymują negatywne opinie w sklepach z aplikacjami związane z awariami interfejsu.

Czym testowanie UI różni się od testów jednostkowych

Główna różnica między testami UI a testami jednostkowymi to poziom abstrakcji. Testy jednostkowe działają na poszczególnych klasach i funkcjach, odizolowanych od frameworka Android lub iOS. Wykonują się na JVM (dla Android) bez uruchamiania emulatora i zajmują milisekundy. Testy UI uruchamiane są na rzeczywistym urządzeniu lub emulatorze, współdziałają z usługami systemowymi i wymagają sekund lub minut na jeden scenariusz.

Różni się także docelowa grupa testów. Testy UI sprawdzają kompleksowe scenariusze użytkownika — rejestrację, składanie zamówienia, wyszukiwanie. Testy jednostkowe pokrywają logikę biznesową: obliczenia, walidację, transformację danych. Test UI nie sprawdza poprawności obliczenia podatku — sprawdza, czy końcowa kwota jest wyświetlana na ekranie. Samo obliczenie jest sprawdzane przez test jednostkowy.

Według Google Testing Blog (2020), optymalna proporcja testów w projekcie powinna odpowiadać regule piramidy testowania: 70% testów jednostkowych, 20% integracyjnych i 10% testów UI. Naruszenie tej proporcji na korzyść testów UI prowadzi do wydłużenia czasu wykonania i kruchości zestawu testów, ponieważ testy UI są wrażliwe na zmiany w układzie ekranów.

Frameworki do testowania UI

Dla Android dominującym frameworkiem jest Espresso — biblioteka od Google wbudowana w AndroidX Test. Espresso automatycznie synchronizuje się z wątkiem UI, oczekując na zakończenie animacji i zadań w tle przed wykonaniem kolejnego sprawdzenia. Dla Jetpack Compose używane jest rozszerzenie Compose UI Test, które działa przez węzły semantyczne zamiast tradycyjnych identyfikatorów widoków.

Dla iOS głównym narzędziem jest XCUITest, wchodzący w skład Xcode. Testy pisane są w Swift i używają identyfikatorów Accessibility do wyszukiwania elementów. XCUITest obsługuje nagrywanie testów przez funkcję record i integrację z systemami CI przez xcodebuild. Dla projektów wieloplatformowych stosowany jest Appium, oparty na protokole WebDriver i umożliwiający uruchamianie tych samych testów na Android i iOS z minimalnymi zmianami w kodzie.

Espresso i Compose UI Test

Espresso działa z tradycyjnym systemem View przez onView i identyfikatory zasobów id. Compose UI Test używa warstwy semantycznej, co czyni testy mniej zależnymi od hierarchii widoków. Na przykład wyszukiwanie przycisku w Espresso: onView(withId(R.id.submit)), w Compose: onNodeWithTag(„submit”). Compose testy automatycznie obsługują rekompozycję i nie wymagają jawnych oczekiwań na stan bezczynności.

XCUITest dla iOS

XCUITest używa XCUIApplication jako punktu wejścia. Każdy element interfejsu jest wyszukiwany przez właściwości Accessibility: accessibilityIdentifier dla dostępu programowego i accessibilityLabel dla VoiceOver. Framework obsługuje nagrywanie testów przez funkcję record w Xcode — programista wykonuje działania na symulatorze, a Xcode generuje kod testu. Gotowe testy uruchamiane są przez xcodebuild test.

Rozwiązania wieloplatformowe

Appium oparty jest na protokole WebDriver i obsługuje dowolne języki: Java, Python, JavaScript. Do wyszukiwania elementów używane są strategie id, xpath, class name i accessibility id. Appium wymaga instalacji serwera i konfiguracji Desired Capabilities — platformName, deviceName, appPackage. Alternatywą jest Maestro, używający scenariuszy YAML i niewymagający kompilacji kodu testowego.

• 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 dla React Native, synchronizujący się z wątkiem JS
• Maestro — nowoczesne narzędzie ze scenariuszami YAML, niewymagające pisania kodu

Przykłady kodu testów UI

Przyjrzyjmy się testom UI dla tego samego scenariusza — logowania do aplikacji — w trzech różnych frameworkach: Espresso dla Android, XCUITest dla iOS i Appium dla podejścia wieloplatformowego. Scenariusz: wprowadź login i hasło, naciśnij przycisk logowania, sprawdź wyświetlenie komunikatu powitalnego.

Android: Espresso

Test w Espresso używa onView do wyszukania elementu po identyfikatorze i perform do wykonania działania. Metoda check z matcherem isDisplayed potwierdza, że element jest widoczny na ekranie.

@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("Witaj, Użytkowniku!")
            .assertIsDisplayed()
    }
}

iOS: XCUITest

XCUITest używa XCUIApplication do dostępu do elementów interfejsu przez identyfikatory Accessibility. Metody tap() i exists zapewniają interakcję i sprawdzenie.

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("uzytkownik@przyklad.com")
        app.secureTextFields["passwordField"].tap()
        app.secureTextFields["passwordField"].typeText("tajne123")
        app.buttons["loginButton"].tap()
        XCTAssertTrue(app.staticTexts["Welcome, User!"].exists)
    }
}

Najlepsze praktyki testowania UI

Pierwsza zasada — używaj identyfikatorów Accessibility zamiast etykiet tekstowych do wyszukiwania elementów. Tekst przycisku może się zmienić przy lokalizacji, a identyfikator pozostanie stabilny. W Android jest to właściwość contentDescription, w iOS — accessibilityIdentifier. Takie podejście czyni testy niezależnymi od języka interfejsu i zmniejsza koszty utrzymania przy zmianie copywritingu.

Unikaj sleep() i stałych opóźnień — używaj wbudowanych mechanizmów oczekiwania frameworka. Espresso automatycznie oczekuje na zakończenie animacji i zadań w tle. XCUITest udostępnia XCTAssertTrue z timeoutem. Jawne pauzy spowalniają testy i czynią je mniej stabilnymi, szczególnie na wolnych urządzeniach w środowisku CI.

Grupuj testy według krytyczności: testy smoke (3–5 kluczowych scenariuszy) uruchamiane są przy każdym commicie, pełny zestaw testów UI — przed wydaniem. Według Google Testing Blog (2022), testy UI zajmujące ponad 30 minut w CI zmniejszają częstotliwość uruchomień o 40%, co obniża ich skuteczność jako narzędzia wczesnego wykrywania regresji.

Ograniczenia testów UI i jak je omijać

Testy UI mają szereg ograniczeń. Wrażliwość na zmiany układu: zmiana identyfikatora, hierarchii lub typu elementu psuje test nawet przy niezmienionej funkcjonalności. Rozwiązanie — użycie wzorca Page Object, centralizującego selektory elementów w oddzielnych klasach. Przy zmianie układu poprawia się jeden plik Page Object, a nie dziesiątki testów.

Czas wykonania: uruchomienie na rzeczywistym urządzeniu lub emulatorze zajmuje 10–50 razy więcej czasu niż test jednostkowy. Rozwiązanie — uruchamianie testów UI równolegle na wielu urządzeniach przez Firebase Test Lab lub AWS Device Farm. Niestabilność (flakiness) — częsty problem uruchomień CI, spowodowany animacjami, opóźnieniami sieciowymi lub stanem emulatora. Do walki z flakiness stosuje się automatyczne ponawianie nieudanych testów i analitykę stabilności każdego scenariusza testowego.