Mobil tətbiqlərdə UI testi: nədir, növləri və necə aparılır

UI testi nədir?

UI testi — test kodunun tətbiqin qrafik interfeysi ilə real istifadəçinin edəcəyi şəkildə qarşılıqlı əlaqədə olduğu avtomatlaşdırılmış yoxlama növüdür. Test ekranda elementi — düyməni, mətn sahəsini, siyahını — tapır, onun üzərində əməliyyat yerinə yetirir və interfeysin gözlənilən reaksiyasını yoxlayır. Məsələn, səhv şifrə daxil etdikdən sonra UI testi ekranda düzgün mətnli xəta mesajının görünüb-görünmədiyini yoxlayır.

UI testlərinin digər avtomatlaşdırma növlərindən əsas fərqi onların tətbiqin daxili API-si vasitəsilə deyil, Accessibility qatı vasitəsilə işləməsidir. Bu o deməkdir ki, UI testləri interfeysi istifadəçi və ekran oxuma sistemi kimi dəqiq görür. Bunun sayəsində UI testləri təkcə funksionallığı deyil, həm də elementlərin əlçatanlığını — WCAG tələblərinə uyğunluğu yoxlayır.

JetBrains Developer Ecosystem 2023 sorğusuna görə, mobil komandaların 58%-i CI/CD boru kəmərində UI testlərindən istifadə edir. Kommersiya layihələrində UI testləri ilə orta əhatə tətbiqin 30–40% ekranlarını təşkil edir. UI testləri olan layihələr interfeys qəzaları ilə bağlı tətbiq mağazalarında 25% daha az mənfi rəy alır.

UI testi vahid testdən nə ilə fərqlənir

UI testləri ilə vahid testlər arasındakı əsas fərq abstraksiya səviyyəsidir. Vahid testlər Android və ya iOS freymvorkundan təcrid olunmuş ayrı-ayrı siniflər və funksiyalar üzərində işləyir. Onlar emulyator işə salmadan JVM-də (Android üçün) icra olunur və millisaniyələr çəkir. UI testləri real cihazda və ya emulyatorda işləyir, sistem xidmətləri ilə qarşılıqlı əlaqədə olur və bir ssenari üçün saniyələr və ya dəqiqələr tələb edir.

Testlərin hədəf auditoriyası da fərqlənir. UI testləri kompleks istifadəçi ssenarilərini — qeydiyyatı, sifarişin verilməsini, axtarışı yoxlayır. Vahid testlər biznes məntiqini əhatə edir: hesablamalar, validasiya, məlumat çevrilməsi. UI testi vergi hesablamasının düzgünlüyünü yoxlamır — o, yekun məbləğin ekranda göstərilməsini yoxlayır. Hesablamanın özü vahid testlə yoxlanılır.

Google Testing Blog (2020)-a görə, layihədə testlərin optimal nisbəti test piramidası qaydasına uyğun olmalıdır: 70% vahid test, 20% inteqrasiya testi və 10% UI testi. Bu nisbətin UI testləri lehinə pozulması icra müddətinin uzanmasına və test dəstinin kövrəkliyinə gətirib çıxarır, çünki UI testləri ekran düzümündəki dəyişikliklərə həssasdır.

UI testi üçün freymvorklar

Android üçün dominant freymvork Espresso — AndroidX Test-ə daxil edilmiş Google kitabxanasıdır. Espresso avtomatik olaraq UI axını ilə sinxronlaşır, növbəti yoxlamadan əvvəl animasiyaların və fon tapşırıqlarının tamamlanmasını gözləyir. Jetpack Compose üçün ənənəvi görüntü identifikatorları \u0259vəzinə semantik düyünlər vasitəsilə işləyən Compose UI Test genişləndirməsi istifadə olunur.

iOS üçün əsas alət Xcode tərkibinə daxil olan XCUITest-dir. Testlər Swift dilində yazılır və elementlərin axtarışı üçün Accessibility identifikatorlarından istifadə edir. XCUITest record funksiyası vasitəsilə test yazılmasını və xcodebuild vasitəsilə CI sistemləri ilə inteqrasiyanı dəstəkləyir. Platformalararası layihələr üçün WebDriver protokoluna əsaslanan və minimal kod dəyişiklikləri ilə Android və iOS-da eyni testləri işə salmağa imkan verən Appium tətbiq olunur.

Espresso və Compose UI Test

Espresso onView və resurs id identifikatorları vasitəsilə ənənəvi View sistemi ilə işləyir. Compose UI Test semantik qatdan istifadə edir ki, bu da testləri görüntü iyerarxiyasından daha az asılı edir. Məsələn, Espresso-da düymə axtarışı: onView(withId(R.id.submit)), Compose-da: onNodeWithTag(“submit”). Compose testləri avtomatik olaraq rekompozisiyanı idarə edir və boş vəziyyət üçün açıq gözləmə tələb etmir.

iOS üçün XCUITest

XCUITest giriş nöqtəsi kimi XCUIApplication-dan istifadə edir. İnterfeysin hər bir elementi Accessibility xüsusiyyətləri vasitəsilə axtarılır: proqram girişi üçün accessibilityIdentifier və VoiceOver üçün accessibilityLabel. Freymvork Xcode-da record funksiyası vasitəsilə test yazılmasını dəstəkləyir — tərtibatçı simulyatorda hərəkətləri yerinə yetirir, Xcode isə test kodunu yaradır. Hazır testlər xcodebuild test vasitəsilə işə salınır.

Platformalararası həllər

Appium WebDriver protokoluna əsaslanır və istənilən dilləri dəstəkləyir: Java, Python, JavaScript. Elementlərin axtarışı üçün id, xpath, class name və accessibility id strategiyaları istifadə olunur. Appium server quraşdırılması və Desired Capabilities — platformName, deviceName, appPackage konfiqurasiyası tələb edir. Alternativ olaraq, YAML ssenarilərindən istifadə edən və test kodunun kompilyasiyasını tələb etməyən Maestro mövcuddur.

• 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 tərəfindən React Native üçün JS axını ilə sinxronlaşan freymvork
• Maestro — YAML ssenariləri ilə kod yazmağı tələb etməyən müasir alət

UI testləri üçün kod nümunələri

Eyni ssenari — tətbiqə daxil olma — üçün UI testlərinə üç fərqli freymvorkda baxaq: Android üçün Espresso, iOS üçün XCUITest və platformalararası yanaşma üçün Appium. Ssenari: login və şifrə daxil edin, daxil olma düyməsini basın, xoş gəldin mesajının göründüyünü yoxlayın.

Android: Espresso

Espresso-da test elementi identifikator üzrə axtarmaq üçün onView və əməliyyatı yerinə yetirmək üçün perform istifadə edir. isDisplayed matcheri ilə check metodu elementin ekranda göründüyünü təsdiqləyir.

@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("Xoş gəldiniz, İstifadəçi!")
            .assertIsDisplayed()
    }
}

iOS: XCUITest

XCUITest interfeys elementlərinə giriş üçün Accessibility identifikatorları vasitəsilə XCUIApplication-dan istifadə edir. tap() və exists metodları qarşılıqlı əlaqə və yoxlama təmin edir.

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

UI testinin ən yaxşı təcrübələri

Birinci prinsip — elementlərin axtarışı üçün mətn etiketləri əvəzinə Accessibility identifikatorlarından istifadə edin. Düymənin mətni lokallaşdırma zamanı dəyişə bilər, identifikator isə sabit qalır. Android-də bu contentDescription xüsusiyyəti, iOS-da isə accessibilityIdentifier-dir. Bu yanaşma testləri interfeys dilindən asılı olmayan edir və kopiraytinq dəyişikliyində texniki xidmət xərclərini azaldır.

sleep() və sabit gecikmələrdən qaçının — freymvorkun daxili gözləmə mexanizmlərindən istifadə edin. Espresso avtomatik olaraq animasiyaların və fon tapşırıqlarının tamamlanmasını gözləyir. XCUITest timeout ilə XCTAssertTrue təmin edir. Açıq fasilələr testləri yavaşlatır və daha az sabit edir, xüsusilə CI mühitində yavaş cihazlarda.

Testləri kritikliyə görə qruplaşdırın: smoke testləri (3–5 əsas ssenari) hər commit-də işə salınır, tam UI test dəsti — buraxılışdan əvvəl. Google Testing Blog (2022)-yə görə, CI-da 30 dəqiqədən çox vaxt aparan UI testləri işə salınma tezliyini 40% azaldır ki, bu da onların reqressiyaların erkən aşkarlanması aləti kimi effektivliyini azaldır.

UI testlərinin məhdudiyyətləri və onları necə aşmaq olar

UI testlərinin bir sıra məhdudiyyətləri var. Düzüm dəyişikliklərinə həssaslıq: identifikatorun, iyerarxiyanın və ya element növünün dəyişməsi dəyişməz funksionallıqda belə testi pozur. Həll yolu — element seçicilərini ayrı siniflərdə mərkəzləşdirən Page Object nümunəsindən istifadə etmək. Düzüm dəyişdikdə onlarla test deyil, bir Page Object faylı düzəlişir.

İcra müddəti: real cihazda və ya emulyatorda işə salma vahid testdən 10–50 dəfə çox vaxt aparır. Həll yolu — Firebase Test Lab və ya AWS Device Farm vasitəsilə UI testlərini bir neçə cihazda paralel işə salmaq. Qeyri-sabitlik (flakiness) — animasiyalar, şəbəkə gecikmələri və ya emulyator vəziyyəti səbəbindən CI işə salmalarının tez-tez rast gəlinən problemi. Flakiness ilə mübarizə üçün uğursuz testlərin avtomatik təkrarlanması və hər test ssenarisinin sabitlik analitikası tətbiq olunur.