Mobil ilovalarda UI testlash: bu nima, turlari va qanday o'tkaziladi

UI testlash nima?

UI testlash — test kodi ilonning grafik interfeysi bilan haqiqiy foydalanuvchi qilganidek o‘zaro aloqada bo‘ladigan avtomatlashtirilgan tekshirish turidir. Test ekranda elementni — tugmani, matn maydonini, ro‘yxatni — topadi, unda amal bajaradi va interfeysning kutilgan reaksiyasini tekshiradi. Masalan, noto‘g‘ri parol kiritilgandan so‘ng, UI testi ekranda to‘g‘ri matnli xato xabari paydo bo‘lganligini tekshiradi.

UI testlarining boshqa avtomatlashtirish turlaridan asosiy farqi shundaki, ular ilonning ichki API-si orqali emas, balki operatsion tizimning Accessibility qatlami orqali ishlaydi. Bu UI testlari interfeysni foydalanuvchi va ekranni o‘qish tizimi kabi aniq ko‘rishini anglatadi. Shu tufayli UI testlari nafaqat funksionallikni, balki elementlarning mavjudligini — WCAG talablariga muvofiqligini ham tekshiradi.

JetBrains Developer Ecosystem 2023 so‘roviga ko‘ra, mobil jamoalarning 58% CI/CD quvurida UI testlaridan foydalanadi. Tijoriy loyihalarda UI testlari bilan o‘rtacha qamrab olish ilova ekranlarining 30–40% ni tashkil qiladi. UI testlari bo‘lgan loyihalar interfeysdagi nosozliklar bilan bog‘liq ilova do‘konlarida 25% kamroq salbiy sharhlar oladi.

UI testlash unit testdan nimasi bilan farq qiladi

UI testlari va unit testlar o‘rtasidagi asosiy farq abstraksiya darajasidir. Unit testlar Android yoki iOS freymvorkidan ajratilgan alohida sinflar va funksiyalar bilan ishlaydi. Ular emulyatorni ishga tushirmasdan JVM da (Android uchun) bajariladi va millisekundlar davom etadi. UI testlari haqiqiy qurilmada yoki emulyatorda ishlaydi, tizim xizmatlari bilan o‘zaro aloqada bo‘ladi va bitta stsenariy uchun soniyalar yoki daqiqalar talab qiladi.

Testlarning maqsadli auditoriyasi ham farqlanadi. UI testlari to‘liq foydalanuvchi stsenariylarini — ro‘yxatdan o‘tish, buyurtma berish, qidirishni tekshiradi. Unit testlar biznes mantiqni qamrab oladi: hisob-kitoblar, validatsiya, ma’lumotlarni o‘zgartirish. UI testi soliq hisobining to‘g‘riligini tekshirmaydi — u yakuniy summaning ekranda ko‘rsatilishini tekshiradi. Hisobning o‘zi unit test bilan tekshiriladi.

Google Testing Blog (2020) ga ko‘ra, loyihadagi testlarning optimal nisbati test piramidasi qoidasiga amal qilishi kerak: 70% unit testlar, 20% integrasion testlar va 10% UI testlari. Bu nisbatning UI testlari foydasiga buzilishi bajarilish vaqtining uzayishiga va testlar to‘plamining mo‘rtligiga olib keladi, chunki UI testlari ekran tartibidagi o‘zgarishlarga sezgir.

UI testlash uchun freymvorklar

Android uchun dominant freymvork Espresso — AndroidX Test tarkibiga kiritilgan Google kutubxonasi. Espresso avtomatik ravishda UI oqimi bilan sinxronlashadi, keyingi tekshirishdan oldin animatsiyalar va fon vazifalarining tugashini kutadi. Jetpack Compose uchun an’anaviy ko‘rinish identifikatorlari o‘rniga semantik tugunlar orqali ishlaydigan Compose UI Test kengaytmasidan foydalaniladi.

iOS uchun asosiy vosita Xcode tarkibiga kiruvchi XCUITest dir. Testlar Swift tilida yoziladi va elementlarni topish uchun Accessibility identifikatorlaridan foydalanadi. XCUITest record funksiyasi orqali testlarni yozib olishni va xcodebuild orqali CI tizimlari bilan integratsiyani qo‘llab-quvvatlaydi. Platformalararo loyihalar uchun WebDriver protokoliga asoslangan va minimal kod o‘zgarishlari bilan Android va iOS da bir xil testlarni ishga tushirishga imkon beruvchi Appium qo‘llaniladi.

Espresso va Compose UI Test

Espresso onView va resurs id identifikatorlari orqali an’anaviy View tizimi bilan ishlaydi. Compose UI Test semantik qatlamdan foydalanadi, bu testlarni ko‘rinish iyerarxiyasiga kamroq bog‘liq qiladi. Masalan, Espresso-da tugmani qidirish: onView(withId(R.id.submit)), Compose-da: onNodeWithTag(“submit”). Compose testlari avtomatik ravishda rekompozitsiyani boshqaradi va bo‘sh holat uchun aniq kutishni talab qilmaydi.

iOS uchun XCUITest

XCUITest kirish nuqtasi sifatida XCUIApplication dan foydalanadi. Interfeysning har bir elementi Accessibility xususiyatlari orqali qidiriladi: dasturiy kirish uchun accessibilityIdentifier va VoiceOver uchun accessibilityLabel. Freymvork Xcode-da record funksiyasi orqali testlarni yozib olishni qo‘llab-quvvatlaydi — dasturchi simulyatorda harakatlarni bajaradi, Xcode esa test kodini yaratadi. Tayyor testlar xcodebuild test orqali ishga tushiriladi.

Platformalararo yechimlar

Appium WebDriver protokoliga asoslangan va istalgan tillarni qo‘llab-quvvatlaydi: Java, Python, JavaScript. Elementlarni qidirish uchun id, xpath, class name va accessibility id strategiyalaridan foydalaniladi. Appium server o‘rnatish va Desired Capabilities — platformName, deviceName, appPackage sozlashni talab qiladi. Muqobil variant — YAML stsenariylaridan foydalanadigan va test kodini kompilyatsiya qilishni talab qilmaydigan Maestro.

• 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 tomonidan React Native uchun JS oqimi bilan sinxronlashadigan freymvork
• Maestro — YAML stsenariylari bilan kod yozishni talab qilmaydigan zamonaviy vosita

UI testlari uchun kod namunalari

Xuddi shu stsenariy — ilovaga kirish — uchun UI testlarini uch xil freymvorkda ko‘rib chiqamiz: Android uchun Espresso, iOS uchun XCUITest va platformalararo yondashuv uchun Appium. Stsenariy: login va parolni kiriting, kirish tugmasini bosing, xush kelibsiz xabarining ko‘rinishini tekshiring.

Android: Espresso

Espresso da test elementni identifikator bo‘yicha qidirish uchun onView va amalni bajarish uchun perform dan foydalanadi. isDisplayed matcheri bilan check metodi elementning ekranda ko‘rinishini tasdiqlaydi.

@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("Xush kelibsiz, Foydalanuvchi!")
            .assertIsDisplayed()
    }
}

iOS: XCUITest

XCUITest interfeys elementlariga kirish uchun Accessibility identifikatorlari orqali XCUIApplication dan foydalanadi. tap() va exists metodlari o‘zaro aloqa va tekshirishni ta’minlaydi.

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

UI testlashning eng yaxshi amaliyotlari

Birinchi tamoyil — elementlarni qidirish uchun matn yorliqlari o‘rniga Accessibility identifikatorlaridan foydalaning. Tugma matni lokalizatsiya paytida o‘zgarishi mumkin, identifikator esa barqaror qoladi. Android-da bu contentDescription xususiyati, iOS da — accessibilityIdentifier. Bunday yondashuv testlarni interfeys tilidan mustaqil qiladi va kopirayting o‘zgarganda texnik xizmat ko‘rsatish xarajatlarini kamaytiradi.

sleep() va qat’iy kechikishlardan saqlaning — freymvorkning o‘rnatilgan kutish mexanizmlaridan foydalaning. Espresso avtomatik ravishda animatsiyalar va fon vazifalarining tugashini kutadi. XCUITest timeout bilan XCTAssertTrue ni taqdim etadi. Aniq pauzalar testlarni sekinlashtiradi va ularni kamroq barqaror qiladi, ayniqsa CI muhitida sekin qurilmalarda.

Testlarni muhimligi bo‘yicha guruhlang: smoke testlari (3–5 asosiy stsenariy) har bir commitda ishga tushiriladi, to‘liq UI testlar to‘plami — chiqarishdan oldin. Google Testing Blog (2022) ga ko‘ra, CI da 30 daqiqadan ko‘proq vaqt oladigan UI testlari ishga tushirish chastotasini 40% ga kamaytiradi, bu ularning regressiyalarni erta aniqlash vositasi sifatida samaradorligini pasaytiradi.

UI testlarining cheklovlari va ularni qanday chetlab o‘tish

UI testlari bir qator cheklovlarga ega. Tartib o‘zgarishlariga sezgirlik: identifikator, iyerarxiya yoki element turining o‘zgarishi o‘zgarmas funksionallikda ham testni buzadi. Yechim — element selektorlarini alohida sinflarda markazlashtiruvchi Page Object namunasidan foydalanish. Tartib o‘zgarganda o‘nlab testlar emas, bitta Page Object fayli tuzatiladi.

Bajarilish vaqti: haqiqiy qurilmada yoki emulyatorda ishga tushirish unit testdan 10–50 baravar ko‘proq vaqt oladi. Yechim — Firebase Test Lab yoki AWS Device Farm orqali UI testlarini bir nechta qurilmada parallel ishga tushirish. Beqarorlik (flakiness) — animatsiyalar, tarmoq kechikishlari yoki emulyator holati tufayli CI ishga tushirishlarining tez-tez uchraydigan muammosi. Flakiness bilan kurashish uchun muvaffaqiyatsiz testlarni avtomatik qayta urinish va har bir test stsenariysining barqarorlik analitikasi qo‘llaniladi.