Pengujian UI di Aplikasi Seluler: Apa Itu, Jenis, dan Cara Melakukannya

Apa itu Pengujian UI?

Pengujian UI adalah jenis pemeriksaan terotomatisasi di mana kode pengujian berinteraksi dengan antarmuka grafis aplikasi persis seperti yang dilakukan pengguna nyata. Pengujian menemukan elemen di layar — tombol, kolom teks, daftar — melakukan tindakan padanya dan memeriksa reaksi antarmuka yang diharapkan. Misalnya, setelah memasukkan kata sandi yang salah, pengujian UI memeriksa apakah pesan kesalahan dengan teks yang benar muncul di layar.

Perbedaan utama antara pengujian UI dan jenis otomatisasi lainnya adalah bahwa mereka bekerja melalui lapisan Accessibility sistem operasi, bukan melalui API internal aplikasi. Ini berarti pengujian UI melihat antarmuka persis seperti yang dilihat pengguna dan sistem pembaca layar. Berkat ini, pengujian UI tidak hanya memeriksa fungsionalitas, tetapi juga aksesibilitas elemen — kepatuhan terhadap persyaratan WCAG.

Menurut survei JetBrains Developer Ecosystem 2023, 58% tim seluler menggunakan pengujian UI dalam pipeline CI/CD mereka. Cakupan rata-rata pengujian UI di proyek komersial adalah 30–40% layar aplikasi. Proyek dengan pengujian UI menerima 25% lebih sedikit ulasan negatif di toko aplikasi terkait crash antarmuka.

Perbedaan Pengujian UI dengan Pengujian Unit

Perbedaan utama antara pengujian UI dan pengujian unit adalah tingkat abstraksi. Pengujian unit bekerja dengan kelas dan fungsi individual, terisolasi dari framework Android atau iOS. Mereka dijalankan di JVM (untuk Android) tanpa memulai emulator dan membutuhkan waktu milidetik. Pengujian UI berjalan di perangkat nyata atau emulator, berinteraksi dengan layanan sistem, dan membutuhkan detik atau menit untuk satu skenario.

Audien target pengujian juga berbeda. Pengujian UI memeriksa skenario pengguna menyeluruh — pendaftaran, pemesanan, pencarian. Pengujian unit mencakup logika bisnis: perhitungan, validasi, transformasi data. Pengujian UI tidak memeriksa kebenaran perhitungan pajak — ia memeriksa apakah jumlah akhir ditampilkan di layar. Perhitungan itu sendiri diperiksa oleh pengujian unit.

Menurut Google Testing Blog (2020), rasio optimal pengujian dalam proyek harus mengikuti aturan piramida pengujian: 70% pengujian unit, 20% pengujian integrasi, dan 10% pengujian UI. Pelanggaran rasio ini demi pengujian UI menyebabkan peningkatan waktu eksekusi dan kerapuhan set pengujian, karena pengujian UI sensitif terhadap perubahan tata letak layar.

Framework untuk Pengujian UI

Untuk Android, framework dominan adalah Espresso — pustaka dari Google yang tertanam di AndroidX Test. Espresso secara otomatis sinkron dengan thread UI, menunggu penyelesaian animasi dan tugas latar belakang sebelum melakukan pemeriksaan berikutnya. Untuk Jetpack Compose digunakan ekstensi Compose UI Test, yang bekerja melalui node semantik alih-alih pengidentifikasi tampilan tradisional.

Untuk iOS, alat utamanya adalah XCUITest, yang merupakan bagian dari Xcode. Pengujian ditulis dalam Swift dan menggunakan pengidentifikasi Accessibility untuk menemukan elemen. XCUITest mendukung perekaman pengujian melalui fungsi record dan integrasi dengan sistem CI melalui xcodebuild. Untuk proyek lintas platform, digunakan Appium, berdasarkan protokol WebDriver yang memungkinkan menjalankan pengujian yang sama di Android dan iOS dengan perubahan minimal dalam kode.

Espresso dan Compose UI Test

Espresso bekerja dengan sistem View tradisional melalui onView dan pengidentifikasi sumber daya id. Compose UI Test menggunakan lapisan semantik, yang membuat pengujian kurang bergantung pada hierarki tampilan. Misalnya, mencari tombol di Espresso: onView(withId(R.id.submit)), di Compose: onNodeWithTag(“submit”). Pengujian Compose secara otomatis menangani rekomposisi dan tidak memerlukan penantian eksplisit untuk status idle.

XCUITest untuk iOS

XCUITest menggunakan XCUIApplication sebagai titik masuk. Setiap elemen antarmuka ditemukan melalui properti Accessibility: accessibilityIdentifier untuk akses programatik dan accessibilityLabel untuk VoiceOver. Framework mendukung perekaman pengujian melalui fungsi record di Xcode — pengembang melakukan tindakan di simulator, dan Xcode menghasilkan kode pengujian. Pengujian yang siap dijalankan melalui xcodebuild test.

Solusi Lintas Platform

Appium didasarkan pada protokol WebDriver dan mendukung bahasa apa pun: Java, Python, JavaScript. Untuk menemukan elemen digunakan strategi id, xpath, class name, dan accessibility id. Appium memerlukan instalasi server dan konfigurasi Desired Capabilities — platformName, deviceName, appPackage. Alternatifnya adalah Maestro, yang menggunakan skenario YAML dan tidak memerlukan kompilasi kode pengujian.

• 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 dari Wix untuk React Native, yang sinkron dengan thread JS
• Maestro — alat modern dengan skenario YAML, tidak memerlukan penulisan kode

Contoh Kode untuk Pengujian UI

Mari kita lihat pengujian UI untuk skenario yang sama — login ke aplikasi — di tiga framework berbeda: Espresso untuk Android, XCUITest untuk iOS, dan Appium untuk pendekatan lintas platform. Skenario: masukkan nama pengguna dan kata sandi, tekan tombol login, periksa tampilan pesan selamat datang.

Android: Espresso

Pengujian di Espresso menggunakan onView untuk menemukan elemen berdasarkan pengidentifikasi dan perform untuk melakukan tindakan. Metode check dengan matcher isDisplayed mengonfirmasi bahwa elemen terlihat di layar.

@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("Selamat datang, Pengguna!")
            .assertIsDisplayed()
    }
}

iOS: XCUITest

XCUITest menggunakan XCUIApplication untuk mengakses elemen antarmuka melalui pengidentifikasi Accessibility. Metode tap() dan exists menyediakan interaksi dan pemeriksaan.

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

Praktik Terbaik Pengujian UI

Prinsip pertama — gunakan pengidentifikasi Accessibility alih-alih label teks untuk menemukan elemen. Teks tombol dapat berubah saat lokalisasi, sementara pengidentifikasi tetap stabil. Di Android ini adalah properti contentDescription, di iOS — accessibilityIdentifier. Pendekatan ini membuat pengujian independen dari bahasa antarmuka dan mengurangi biaya pemeliharaan saat perubahan copywriting.

Hindari sleep() dan penundaan tetap — gunakan mekanisme penantian bawaan framework. Espresso secara otomatis menunggu penyelesaian animasi dan tugas latar belakang. XCUITest menyediakan XCTAssertTrue dengan timeout. Jeda eksplisit memperlambat pengujian dan membuatnya kurang stabil, terutama pada perangkat lambat di lingkungan CI.

Kelompokkan pengujian berdasarkan kekritisan: pengujian smoke (3–5 skenario kunci) dijalankan pada setiap commit, set pengujian UI lengkap — sebelum rilis. Menurut Google Testing Blog (2022), pengujian UI yang memakan waktu lebih dari 30 menit di CI mengurangi frekuensi eksekusi sebesar 40%, yang menurunkan efektivitasnya sebagai alat deteksi dini regresi.

Keterbatasan Pengujian UI dan Cara Mengatasinya

Pengujian UI memiliki sejumlah keterbatasan. Kepekaan terhadap perubahan tata letak: perubahan pengidentifikasi, hierarki, atau jenis elemen merusak pengujian bahkan dengan fungsionalitas yang tidak berubah. Solusi — penggunaan pola Page Object, yang memusatkan pemilih elemen di kelas terpisah. Saat perubahan tata letak, satu file Page Object diperbaiki, bukan puluhan pengujian.

Waktu eksekusi: menjalankan di perangkat nyata atau emulator memakan waktu 10–50 kali lebih lama daripada pengujian unit. Solusi — menjalankan pengujian UI secara paralel di beberapa perangkat melalui Firebase Test Lab atau AWS Device Farm. Ketidakstabilan (flakiness) — masalah umum pada eksekusi CI, disebabkan oleh animasi, penundaan jaringan, atau status emulator. Untuk memerangi flakiness, diterapkan pengulangan otomatis pengujian yang gagal dan analitik stabilitas setiap skenario pengujian.