Menskalakan pengujian Anda dengan Perangkat yang Dikelola Gradle

Perangkat yang Dikelola Gradle meningkatkan konsistensi, performa, dan keandalan untuk pengujian berinstrumen otomatis Anda. Fitur ini, yang tersedia untuk API level 27 dan yang lebih tinggi, memungkinkan Anda mengonfigurasi perangkat pengujian virtual dalam file Gradle project. Sistem build menggunakan konfigurasi untuk sepenuhnya mengelola—yaitu membuat, men-deploy, dan menghapus—perangkat tersebut saat menjalankan pengujian otomatis.

Fitur ini memberikan visibilitas Gradle tidak hanya pada pengujian yang Anda jalankan, tetapi juga siklus proses perangkat, sehingga meningkatkan kualitas pengalaman pengujian Anda dengan cara berikut:

  • Menangani masalah terkait perangkat untuk memastikan pengujian Anda dijalankan
  • Memanfaatkan snapshot emulator untuk mempercepat waktu startup perangkat dan penggunaan memori, serta memulihkan perangkat ke kondisi bersih di antara pengujian
  • Meng-cache hasil pengujian dan hanya menjalankan ulang pengujian yang kemungkinan akan memberikan hasil yang berbeda
  • Memberikan lingkungan yang konsisten untuk menjalankan pengujian antara pengujian lokal dan jarak jauh

Selain itu, Perangkat yang Dikelola Gradle memperkenalkan jenis perangkat emulator baru, yang disebut Perangkat Pengujian Otomatis (ATD), yang dioptimalkan untuk meningkatkan performa saat menjalankan pengujian berinstrumen Anda. Bersama dengan dukungan untuk sharding pengujian, Anda dapat bereksperimen dengan membagi rangkaian pengujian di beberapa instance ATD untuk mengurangi waktu eksekusi uji secara keseluruhan.

Membuat perangkat yang dikelola Gradle

Anda dapat menentukan perangkat virtual mana yang digunakan Gradle untuk menguji aplikasi di file build.gradle level modul. Contoh kode berikut membuat Pixel 2 yang menjalankan API level 30 sebagai perangkat yang dikelola Gradle.

android {
  testOptions {
    managedDevices {
      devices {
        pixel2api30 (com.android.build.api.dsl.ManagedVirtualDevice) {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // Use only API levels 27 and higher.
          apiLevel = 30
          // To include Google services, use "google".
          systemImageSource = "aosp"
        }
      }
    }
  }
}

Untuk menjalankan pengujian menggunakan perangkat yang dikelola Gradle yang dikonfigurasi, gunakan perintah berikut. device-name adalah nama perangkat yang Anda konfigurasi dalam skrip build Gradle (seperti pixel2api30), dan BuildVariant adalah varian build aplikasi yang ingin Anda uji.

gradlew device-nameBuildVariantAndroidTest

Menentukan grup perangkat

Untuk membantu menskalakan pengujian di beberapa konfigurasi perangkat, seperti API level dan faktor bentuk yang berbeda, Anda dapat menentukan beberapa perangkat yang dikelola Gradle dan menambahkannya ke grup bernama. Gradle kemudian dapat menjalankan pengujian Anda di semua perangkat dalam grup secara paralel.

Contoh di bawah ini menunjukkan dua perangkat terkelola yang ditambahkan ke grup perangkat bernama phoneAndTablet.

testOptions {
  managedDevices {
    devices {
      pixel2api29 (com.android.build.api.dsl.ManagedVirtualDevice) { ... }
      nexus9api30 (com.android.build.api.dsl.ManagedVirtualDevice) { ... }
    }
    groups {
      phoneAndTablet {
        targetDevices.add(devices.pixel2api29)
        targetDevices.add(devices.nexus9api30)
      }
    }
  }
}

Untuk menjalankan pengujian menggunakan grup perangkat yang dikelola Gradle, gunakan perintah berikut:

gradlew group-nameGroupBuildVariantAndroidTest

Menjalankan pengujian menggunakan Perangkat Pengujian Otomatis

Perangkat yang Dikelola Gradle mendukung jenis perangkat emulator baru, yang disebut Perangkat Pengujian Otomatis (ATD), yang dioptimalkan untuk mengurangi resource CPU dan memori saat menjalankan pengujian berinstrumen. ATD meningkatkan performa runtime dengan beberapa cara:

  • Menghapus aplikasi bawaan yang biasanya tidak berguna untuk menguji aplikasi Anda
  • Menonaktifkan layanan latar belakang tertentu yang biasanya tidak berguna untuk menguji aplikasi Anda
  • Menonaktifkan rendering hardware

Sebelum memulai, pastikan Anda mengupdate Android Emulator ke versi terbaru yang tersedia. Kemudian, tentukan image "-atd" saat menentukan Perangkat yang Dikelola Gradle di build.gradle, seperti yang ditunjukkan di bawah:

android {
  testOptions {
    managedDevices {
      devices {
        pixel2api30 (com.android.build.api.dsl.ManagedVirtualDevice) {
          // Use device profiles you typically see in Android Studio.
          device = "Pixel 2"
          // ATDs currently support only API level 30.
          apiLevel = 30
          // You can also specify "google-atd" if you require Google Play Services.
          systemImageSource = "aosp-atd"
        }
      }
    }
  }
}

Anda juga dapat membuat grup perangkat seperti yang Anda lakukan dengan Perangkat yang Dikelola Gradle lainnya. Untuk memanfaatkan peningkatan performa lebih lanjut, Anda juga dapat menggunakan ATD dengan sharding pengujian untuk mengurangi total waktu eksekusi uji pada rangkaian pengujian Anda.

Apa yang dihapus dari image ATD?

Selain beroperasi dalam mode headless, ATD juga mengoptimalkan performa dengan menghapus atau menonaktifkan aplikasi dan layanan yang biasanya tidak diperlukan untuk menguji kode aplikasi Anda. Tabel di bawah memberikan ringkasan komponen yang telah kami hapus atau nonaktifkan dalam image ATD dan deskripsi alasan mengapa komponen tersebut mungkin tidak berguna.

Yang dihapus di image ATD Alasan mengapa Anda mungkin tidak memerlukannya saat menjalankan pengujian otomatis
Aplikasi produk Google:
  • Email
  • Maps
  • Chrome
  • Messages
  • Play Store, dan lainnya
Pengujian otomatis harus berfokus pada logika aplikasi Anda sendiri sambil mengasumsikan bahwa aplikasi atau platform lain akan berfungsi dengan benar.

Dengan Intent Espresso, Anda dapat mencocokkan dan memvalidasi intent keluar Anda atau bahkan memberikan respons stub sebagai pengganti respons intent yang sebenarnya.

Aplikasi dan layanan setelan:
  • CarrierConfig
  • EmergencyInfo
  • OneTimeInitializer
  • PhotoTable (screensaver)
  • Provision
  • Aplikasi Setelan
  • StorageManager
  • Konfigurasi APN Telepon
  • WallpaperCropper
  • WallpaperPicker
Aplikasi ini menyediakan GUI bagi pengguna akhir untuk mengubah setelan platform, menyiapkan perangkat, atau mengelola penyimpanan perangkat. Ini biasanya berada di luar cakupan pengujian otomatis tingkat aplikasi.


Catatan: Penyedia setelan masih tersedia di image ATD.

SystemUI Pengujian otomatis harus berfokus pada logika aplikasi Anda sendiri sambil mengasumsikan bahwa aplikasi atau platform lain akan berfungsi dengan benar.
Aplikasi dan layanan AOSP:
  • Browser2
  • Kalender
  • Camera2
  • Kontak
  • Telepon
  • DeskClock
  • Galeri2
  • LatinIME
  • Launcher3QuickStep
  • Musik
  • QuickSearchBox
  • SettingsIntelligence
Aplikasi dan layanan ini biasanya berada di luar cakupan pengujian otomatis untuk kode aplikasi Anda.

Mengaktifkan sharding pengujian

Perangkat yang Dikelola Gradle mendukung sharding pengujian, yang memungkinkan Anda membagi rangkaian pengujian di sejumlah instance perangkat virtual yang identik, yang disebut shard, yang berjalan secara paralel. Menggunakan sharding pengujian dapat membantu mengurangi waktu eksekusi uji secara keseluruhan dengan mengorbankan resource komputasi tambahan.

Untuk menetapkan jumlah shard yang ingin Anda gunakan dalam pengujian tertentu, tetapkan hal berikut dalam file gradle.properties Anda:

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

Saat menjalankan pengujian menggunakan opsi ini, Perangkat yang Dikelola Gradle akan menyediakan jumlah shard yang Anda tentukan untuk setiap profil perangkat selama pengujian dijalankan. Jadi, misalnya, jika Anda men-deploy pengujian ke grup perangkat yang terdiri dari tiga perangkat dan menetapkan numManagedDeviceShards ke dua, Perangkat yang Dikelola Gradle akan menyediakan total enam perangkat virtual untuk menjalankan pengujian.

Setelah pengujian selesai, Gradle akan meng-output hasil pengujian dalam file .proto untuk setiap shard yang digunakan dalam pengujian.