Setiap modul pengujian baru harus memiliki file konfigurasi untuk mengarahkan sistem pembangunan dengan metadata modul, dependensi waktu kompilasi, dan instruksi pengemasan. Android sekarang menggunakan sistem pembangunan Soong untuk konfigurasi pengujian yang lebih sederhana.
Soong menggunakan file Blueprint atau .bp , yang merupakan deskripsi deklaratif sederhana seperti JSON dari modul yang akan dibuat. Format ini menggantikan sistem berbasis Make yang digunakan pada rilis sebelumnya. Lihat file referensi Soong di Dasbor Integrasi Berkelanjutan untuk detail selengkapnya.
Untuk mengakomodasi pengujian kustom atau menggunakan Android Compatibility Test Suite (CTS), ikuti Konfigurasi Pengujian Kompleks sebagai gantinya.
Contoh
Entri di bawah ini berasal dari contoh file konfigurasi Blueprint: /platform_testing/tests/example/instrumentation/Android.bp
Sebuah snapshot disertakan di sini untuk kenyamanan:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["android-support-test"],
certificate: "platform",
test_suites: ["device-tests"],
}
Perhatikan deklarasi android_test di awal menunjukkan ini adalah ujian. Menyertakan android_app sebaliknya akan menunjukkan bahwa ini adalah paket build.
Pengaturan
Pengaturan berikut mengumpulkan penjelasan:
name: "HelloWorldTests",
Pengaturan name diperlukan saat jenis modul android_test ditentukan (di awal blok). Ini memberi nama untuk modul Anda, dan APK yang dihasilkan akan diberi nama yang sama dan dengan akhiran .apk , misalnya dalam hal ini, apk pengujian yang dihasilkan dinamai HelloWorldTests.apk . Selain itu, ini juga mendefinisikan nama target make untuk modul Anda, sehingga Anda dapat menggunakan make [options] <HelloWorldTests> untuk membangun modul pengujian Anda dan semua dependensinya.
static_libs: ["android-support-test"],
Pengaturan static_libs menginstruksikan sistem pembangunan untuk memasukkan konten modul bernama ke dalam apk yang dihasilkan dari modul saat ini. Ini berarti bahwa setiap modul bernama diharapkan menghasilkan file .jar , dan kontennya akan digunakan untuk menyelesaikan referensi classpath selama waktu kompilasi, serta dimasukkan ke dalam apk yang dihasilkan.
Dalam contoh ini, hal-hal yang mungkin berguna secara umum untuk pengujian:
android-support-test adalah bawaan untuk Android Test Support Library, yang mencakup test runner baru AndroidJUnitRunner : pengganti InstrumentationTestRunner bawaan yang sekarang sudah tidak digunakan lagi, dengan dukungan untuk framework pengujian JUnit4. Baca selengkapnya di Menguji aplikasi di Android .
Jika Anda membuat modul instrumentasi baru, Anda harus selalu memulai dengan library android-support-test sebagai runner pengujian Anda. Pohon sumber platform juga mencakup kerangka kerja pengujian berguna lainnya seperti ub-uiautomator , mockito-target , easymock dan banyak lagi.
certificate: "platform",
Pengaturan certificate menginstruksikan sistem build untuk menandatangani apk dengan sertifikat yang sama dengan platform inti. Ini diperlukan jika pengujian Anda menggunakan izin atau API yang dilindungi tanda tangan. Perhatikan bahwa ini cocok untuk pengujian berkelanjutan platform, tetapi tidak boleh digunakan dalam modul pengujian CTS. Perhatikan bahwa contoh ini menggunakan pengaturan sertifikat ini hanya untuk tujuan ilustrasi: kode pengujian contoh sebenarnya tidak memerlukan apk pengujian untuk ditandatangani dengan sertifikat platform khusus.
Jika Anda menulis instrumentasi untuk komponen Anda yang berada di luar server sistem, yaitu, itu dikemas kurang lebih seperti apk aplikasi biasa, kecuali bahwa itu dibangun ke dalam citra sistem dan mungkin merupakan aplikasi istimewa, kemungkinan instrumentasi Anda akan menargetkan paket aplikasi (lihat bagian di bawah tentang manifes) komponen Anda. Dalam hal ini, makefile aplikasi Anda mungkin memiliki pengaturan certificate sendiri, dan modul instrumentasi Anda harus mempertahankan pengaturan yang sama. Ini karena untuk menargetkan instrumentasi Anda pada aplikasi yang sedang diuji, apk pengujian dan apk aplikasi Anda harus ditandatangani dengan sertifikat yang sama.
Dalam kasus lain, Anda tidak perlu memiliki pengaturan ini sama sekali: sistem build hanya akan menandatanganinya dengan sertifikat bawaan default, berdasarkan varian build, dan biasanya disebut dev-keys .
test_suites: ["device-tests"],
Pengaturan test_suites membuat tes mudah ditemukan oleh test harness Trade Federation. Suite lain dapat ditambahkan di sini seperti CTS sehingga tes ini dapat dibagikan.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Pengaturan opsional
Pengaturan opsional berikut mengumpulkan penjelasan:
test_config: "path/to/hello_world_test.xml"
Pengaturan test_config menginstruksikan sistem pembangunan target pengujian Anda memerlukan konfigurasi khusus. Secara default, AndroidTest.xml di sebelah Android.bp dikaitkan dengan konfigurasi.
auto_gen_config: true
Pengaturan auto_gen_config menunjukkan apakah akan membuat konfigurasi pengujian secara otomatis atau tidak. Jika AndroidTest.xml tidak ada di sebelah Android.bp , atribut ini tidak perlu disetel ke true secara eksplisit.
require_root: true
Pengaturan require_root menginstruksikan sistem build untuk menambahkan RootTargetPreparer ke konfigurasi pengujian yang dibuat secara otomatis. Ini menjamin pengujian berjalan dengan izin root.
test_min_api_level: 29
Pengaturan test_min_api_level menginstruksikan sistem build untuk menambahkan MinApiLevelModuleController ke konfigurasi pengujian yang dibuat secara otomatis. Saat Federasi Perdagangan menjalankan konfigurasi pengujian, pengujian akan dilewati jika properti perangkat dari ro.product.first_api_level < test_min_api_level .