UI тестирање у мобилним апликацијама: шта је, врсте и како се проводи

Шта је UI тестирање?

UI тестирање је врста аутоматизоване провере у којој тестни код интерагује са графичким интерфејсом апликације исто као што би то радио реалан корисник. Тест проналази на екрану елеменат — дугме, текстуално поље, листу — извршава акцију на њему и проверава очекивану реакцију интерфејса. На пример, након уношења неисправне лозинке, UI тест проверава да ли се на екрану појавила порука о грешци са исправним текстом.

Главна разлика између UI тестова и других врста аутоматизације је што они раде кроз асесибилност слој оперативног система, а не кроз унутрашњи API апликације. То значи да UI тестови виде интерфејс потпуно исто као корисник и систем за читање екрана. Захваљујући томе, UI тестови проверавају не само функционалност, већ и приступачност елемената — усаглашеност са WCAG захтевима.

Према истраживању JetBrains Developer Ecosystem 2023, 58% мобилних тимова користи UI тестове у свом CI/CD пајплајну. Просечно покривање UI тестовима у комерцијалним пројектима износи 30–40% екрана апликације. Пројекти са UI тестовима 25% ређе добијају негативне оцене у продавницама апликација везане за падове интерфејса.

По чему се UI тестирање разликује од јединичног

Главна разлика између UI тестова и јединичних тестова је ниво апстракције. Јединични тестови раде са појединачним класама и функцијама, изолованим од Android или iOS оквира. Извршавају се на JVM (за Android) без покретања емулатора и трају милисекунде. UI тестови се покрећу на реалном уређају или емулатору, интерагују са системским услугама и захтевају секунде или минуте за један сценариј.

Разликује се и циљна публика тестова. UI тестови проверавају целовите корисничке сценарије — регистрацију, поручивање, претрагу. Јединични тестови покривају пословну логику: прорачуне, валидацију, трансформацију података. UI тест не проверава исправност обрачуна пореза — он проверава да ли се коначни износ приказује на екрану. Сам обрачун се проверава јединичним тестом.

Према Google Testing Blog (2020), оптимални однос тестова у пројекту треба да прати правило пирамиде тестирања: 70% јединичних тестова, 20% интеграционих и 10% UI тестова. Кршење овог односа у корист UI тестова доводи до повећања времена извршења и крхкости тестног скупа, јер су UI тестови осетљиви на промене у распореду екрана.

Оквири за UI тестирање

За Android доминантни оквир је Espresso — библиотека од Google уграђена у AndroidX Test. Espresso се аутоматски синхронизује са UI нити, чекајући завршетак анимација и позадинских задатака пре него што изврши следећу проверу. За Jetpack Compose користи се проширење Compose UI Test, које ради кроз семантичке чворове уместо традиционалних идентификатора приказа.

За iOS главни алат је XCUITest, који је саставни део Xcode. Тестови се пишу на Swift-у и користе Accessibility идентификаторе за проналажење елемената. XCUITest подржава снимање тестова кроз record функцију и интеграцију са CI системима кроз xcodebuild. За вишеплатформне пројекте примењује се Appium, заснован на WebDriver протоколу, који омогућуће покретање истих тестова на Android и iOS са минималним изменама у коду.

Espresso и Compose UI Test

Espresso ради са традиционалним View системом кроз onView и id идентификаторе ресурса. Compose UI Test користи семантички слој, што чини тестове мање зависним од хијерархије приказа. На пример, проналажење дугмета у Espresso: onView(withId(R.id.submit)), у Compose: onNodeWithTag(„submit”). Compose тестови аутоматски обрађају рекомпозицију и не захтевају експлицитно чекање на стање мировања.

XCUITest за iOS

XCUITest користи XCUIApplication као улазну тачку. Сваки елеменат интерфејса се проналази кроз Accessibility својства: accessibilityIdentifier за програмски приступ и accessibilityLabel за VoiceOver. Оквир подржава снимање тестова кроз record функцију у Xcode-у — програмер извршава акције на симулатору, а Xcode генерише тестни код. Готови тестови се покрећу кроз xcodebuild test.

Вишеплатформна решења

Appium је заснован на WebDriver протоколу и подржава било који језик: Java, Python, JavaScript. За проналажење елемената користе се стратегије id, xpath, class name и accessibility id. Appium захтева инсталацију сервера и подешавање Desired Capabilities — platformName, deviceName, appPackage. Алтернатива је Maestro, који користи YAML сценарије и не захтева компилацију тестног кода.

• 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 — оквир од Wix за React Native који се синхронизује са JS нити
• Maestro — савремени алат са YAML сценаријима који не захтева писање кода

Примери кода за UI тестове

Погледајмо UI тестове за исти сценариј — пријаву на апликацију — у три различита оквира: Espresso за Android, XCUITest за iOS и Appium за вишеплатформни приступ. Сценариј: унесите корисничко име и лозинку, притисните дугме за пријаву, проверите приказ поруке добродошлице.

Android: Espresso

Тест у Espresso користи onView за проналажење елемента по идентификатору и perform за извршавање акције. Метода check са matcher-ом isDisplayed потврђује да је елеменат видљив на екрану.

@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("Добро дошли, Корисниче!")
            .assertIsDisplayed()
    }
}

iOS: XCUITest

XCUITest користи XCUIApplication за приступ елементима интерфејса кроз Accessibility идентификаторе. Методе tap() и exists омогућују интеракцију и проверу.

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

Најбоље праксе UI тестирања

Први принцип — користите Accessibility идентификаторе уместо текстуалних ознака за проналажење елемената. Текст дугмета се може променити при локализацији, а идентификатор ће остати стабалан. У Android-у је то својство contentDescription, у iOS-у — accessibilityIdentifier. Овакав приступ чини тестове независним од језика интерфејса и смањује трошкове одржавања при промени копирајтинга.

Избегавајте sleep() и фиксних кашњења — користите уграђене механизме чекања оквира. Espresso аутоматски чека завршетак анимација и позадинских задатака. XCUITest пружа XCTAssertTrue са timeout-ом. Експлицитне паузе успоравају тестове и чине их мање стабилним, посебно на спорим уређајима у CI окружењу.

Групишите тестове по критичности: smoke тестови (3–5 кључних сценарија) покрећу се на сваки комит, пун сет UI тестова — пре издавања. Према Google Testing Blog (2022), UI тестови који трају дуже од 30 минута у CI-ју смањују учесталост покретања за 40%, што смањује њихову ефикасност као алата за рано откривање регресија.

Ограничења UI тестова и како их заобићи

UI тестови имају низ ограничења. Осетљивост на промене распореда: промена идентификатора, хијерархије или типа елемента квари тест чак и са непромењеном функционалношћу. Решење — коришћење Page Object обрасца, који централизује селекторе елемената у одвојене класе. При промени распореда прави се један фајл Page Object, а не десетине тестова.

Време извршења: покретање на реалном уређају или емулатору траје 10–50 пута дуже од јединичног теста. Решење — паралелно покретање UI тестова на више уређаја кроз Firebase Test Lab или AWS Device Farm. Нестабилност (flakiness) — чест проблем CI покретања, изазван анимацијама, мрежним кашњењима или стањем емулатора. За борбу са flakiness примењују се аутоматско понављање палих тестова и анализа стабилности сваког тестног сценарија.