Pengujian Aplikasi Mobile: Emulator, Simulator, dan Perangkat Nyata

Kamu baru saja selesai membangun aplikasi mobile. Aplikasi berjalan sempurna di laptop, build sudah ditandatangani dan siap. Kamu merasa percaya diri untuk mengirimkannya ke toko aplikasi. Tapi inilah kenyataan yang tidak mengenakkan: laptop kamu bukanlah ponsel pengguna. Jauh dari itu.

Pengguna menjalankan aplikasi kamu di ratusan perangkat berbeda. Ukuran layar yang berbeda, versi OS, level baterai, kondisi jaringan, dan konfigurasi hardware yang beragam. Bug yang tidak pernah muncul di mesin development bisa membuat aplikasi crash di model ponsel tertentu. Satu rilis yang buruk bisa menghancurkan rating toko dan kehilangan pengguna dalam semalam.

Menguji aplikasi mobile bukanlah pilihan. Tapi bagaimana kamu menguji, dan di mana kamu menjalankan pengujian tersebut, membuat perbedaan besar dalam seberapa percaya diri kamu sebelum merilis.

Lapisan Pengujian yang Penting

Pengujian mobile bukanlah satu hal. Ini adalah tumpukan lapisan, masing-masing menangkap jenis masalah yang berbeda dengan kecepatan yang berbeda.

Unit test berada di lapisan paling bawah. Mereka memverifikasi bahwa satu bagian perilaku bekerja dengan benar. Dalam istilah mobile, ini berarti menguji dari titik masuk yang bermakna: apakah ViewModel bereaksi dengan benar ketika pengguna menekan tombol? Apakah use case mengembalikan output yang tepat untuk input tertentu? Kamu tidak menguji detail implementasi internal. Kamu menguji perilaku yang dapat diamati. Unit test berjalan cepat, seringkali dalam hitungan milidetik. Kamu bisa memicunya pada setiap perubahan kode di pipeline menggunakan emulator atau simulator. Tidak perlu perangkat fisik.

Integration test berada satu tingkat di atas. Mereka memeriksa bagaimana komponen bekerja bersama. Apakah data dari API benar-benar ditampilkan dengan benar di layar? Apakah penyimpanan lokal berfungsi setelah pengguna login? Pengujian ini membutuhkan lingkungan yang mirip dengan perangkat nyata. Emulator, simulator, atau perangkat asli semuanya bisa digunakan di sini, tergantung pada apa yang diintegrasikan.

UI test berada di lapisan teratas. Mereka mensimulasikan interaksi pengguna yang sebenarnya: menekan tombol, mengisi formulir, menggulir daftar, dan memverifikasi bahwa elemen yang diharapkan muncul di layar. Pengujian ini adalah yang paling dekat dengan apa yang sebenarnya dialami pengguna. Mereka juga yang paling lambat dan paling rapuh. Perubahan tata letak kecil bisa merusaknya. Tapi ketika lulus, kamu tahu aplikasi berfungsi dari sudut pandang pengguna.

Setiap lapisan memiliki tempatnya. Unit test memberikan umpan balik cepat. Integration test menangkap masalah perangkaian. UI test memvalidasi pengalaman. Kamu membutuhkan ketiganya, tapi kamu tidak perlu menjalankan semuanya pada setiap pemicu.

Emulator dan Simulator: Cepat Tapi Tidak Sempurna

Emulator (Android) dan simulator (iOS) adalah kuda kerja pengujian mobile. Mereka gratis, mudah dijalankan di pipeline CI/CD, dan cukup baik untuk sebagian besar pemeriksaan logika dan tata letak.

Kamu bisa menjalankan unit test, integration test, dan bahkan UI test di atasnya. Mereka boot dengan cepat, mendukung versi OS yang berbeda, dan memungkinkan kamu mensimulasikan berbagai ukuran layar. Untuk pengembangan sehari-hari dan build internal, mereka biasanya sudah cukup.

Tapi mereka memiliki titik buta. Emulator dan simulator tidak mereproduksi perilaku perangkat nyata. Performa berbeda. Konsumsi baterai berbeda. Respons sensor berbeda. Perilaku jaringan pada seluler berbeda. Tes yang lulus sempurna di emulator bisa gagal di perangkat fisik karena timing, tekanan memori, atau keanehan spesifik hardware.

Untuk membuatnya praktis, berikut adalah job GitHub Actions yang membuat emulator Android, menunggu hingga boot, menjalankan tes instrumentasi, dan mengumpulkan hasilnya:

name: Android Instrumented Tests

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Create and start emulator
        run: |
          echo "no" | avdmanager create avd -n testDevice -k "system-images;android-33;google_apis;x86_64" --force
          $ANDROID_HOME/emulator/emulator -avd testDevice -no-window -no-audio &

      - name: Wait for emulator to boot
        run: |
          adb wait-for-device
          adb shell settings put global window_animation_scale 0.0
          adb shell settings put global transition_animation_scale 0.0
          adb shell settings put global animator_duration_scale 0.0

      - name: Run instrumented tests
        run: ./gradlew connectedCheck

      - name: Upload test results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: app/build/reports/androidTests/connected/

Jika kamu hanya menguji di emulator, kamu merilis dengan informasi yang tidak lengkap.

Device Farm: Hardware Nyata dalam Skala Besar

Di sinilah device farm berperan. Device farm adalah layanan yang memberimu akses ke ponsel dan tablet nyata yang berada di pusat data. Kamu mengunggah aplikasi, menjalankan pengujian di puluhan perangkat secara bersamaan, dan mendapatkan laporan yang menunjukkan apa yang lulus dan apa yang rusak di setiap perangkat.

Opsi populer termasuk Firebase Test Lab untuk Android dan iOS, serta AWS Device Farm. Layanan ini mendukung model perangkat, versi OS, dan ukuran layar yang berbeda. Kamu bisa mengintegrasikannya langsung ke pipeline CI/CD. Setiap kali build selesai, pipeline memicu pengujian di hardware nyata sebelum aplikasi mencapai toko.

Device farm menangkap masalah yang terlewatkan oleh emulator. Crash di hardware tertentu, masalah tata letak di rasio layar yang tidak biasa, degradasi performa di perangkat lama. Mereka juga memberikan tangkapan layar dan log dari setiap proses pengujian, memudahkan diagnosis kegagalan.

Tapi device farm tidak gratis. Mereka membutuhkan biaya per proses pengujian, dan pengujian memakan waktu lebih lama daripada pengujian emulator. Kamu tidak ingin menjalankan setiap build melalui device farm. Itu akan lambat dan mahal.

Kapan Menggunakan Apa

Keputusannya praktis, bukan ideologis. Gunakan emulator dan simulator untuk umpan balik cepat selama pengembangan dan untuk build internal. Gunakan device farm secara strategis sebelum rilis.

Diagram alir berikut merangkum lingkungan yang direkomendasikan untuk setiap jenis pengujian berdasarkan kebutuhan kecepatan dan ketepatan:

flowchart TD A[Jenis Pengujian] --> B{Unit Test?} B -->|Ya| C[Emulator / Simulator] B -->|Tidak| D{Integration Test?} D -->|Ya| E[Emulator / Simulator] D -->|Tidak| F{End-to-End Test?} F -->|Ya| G{Release Candidate?} G -->|Ya| H[Device Farm] G -->|Tidak| I[Emulator / Simulator] F -->|Tidak| J[Manual atau Eksplorasi] C --> K[Umpan balik cepat, ketepatan rendah] E --> K I --> K H --> L[Lebih lambat, ketepatan tinggi] J --> M[Perangkat nyata lebih disukai]

Berikut aturan praktis yang sederhana:

  • Setiap commit: jalankan unit test di emulator atau simulator.
  • Setiap pull request: jalankan unit test plus integration test di emulator atau simulator.
  • Sebelum rilis bertahap atau rilis terfase: jalankan rangkaian pengujian lengkap di device farm, mencakup serangkaian perangkat yang representatif.

Kuncinya adalah menyesuaikan intensitas pengujian dengan risiko. Perbaikan bug kecil di fitur internal tidak perlu menjalankan device farm secara penuh. Rilis yang akan menjangkau ribuan pengguna pasti membutuhkannya.

Daftar Periksa Praktis Sebelum Pengiriman ke Toko

Sebelum kamu menekan tombol kirim di dasbor toko aplikasi, jalankan daftar periksa singkat ini:

  • Unit test lulus di emulator atau simulator untuk versi OS target.
  • Integration test lulus untuk alur pengguna utama (login, tampilan data, navigasi).
  • UI test lulus di setidaknya satu emulator dan satu perangkat fisik.
  • Device farm test lulus untuk 5-10 model perangkat teratas yang menurut analitik kamu benar-benar digunakan pengguna.
  • Tidak ada laporan crash atau ANR (application not responding) dari proses device farm.
  • Tangkapan layar dari device farm sesuai dengan tata letak yang diharapkan di berbagai ukuran layar.

Daftar periksa ini tidak lengkap, tapi menangkap masalah paling umum yang lolos ke produksi.

Kesimpulan Konkret

Menguji hanya di emulator seperti test drive mobil di tempat parkir. Ini memberitahu bahwa setir berfungsi, tapi tidak memberitahu bagaimana mobil menangani jalan raya. Device farm memberikan data jalan raya. Gunakan emulator untuk kecepatan dan device farm untuk kepercayaan diri. Otomatiskan keduanya di pipeline kamu, dan kamu akan mengirimkan lebih sedikit bug dan tidur lebih nyenyak di malam hari.