Halaman ini menjelaskan apa yang dapat disesuaikan untuk modul rangkaian (AndroidTest.xml) melalui sharding dan mendapatkan performa kecepatan terbaik selama eksekusi berkelanjutan di lab. Kami akan mencoba menjelaskan opsi secara umum dengan alasan penggunaan masing-masing opsi.
Saat menjalankan rangkaian secara berkelanjutan di lab, rangkaian biasanya di-shard di beberapa perangkat untuk mengurangi waktu penyelesaian keseluruhan. Harness biasanya mencoba menyeimbangkan waktu eksekusi setiap shard untuk meminimalkan waktu penyelesaian keseluruhan (saat shard terakhir selesai); tetapi karena sifat beberapa pengujian, kita tidak selalu memiliki introspeksi yang cukup dan memerlukan pemilik modul untuk menyesuaikan beberapa perilaku.
Dapat di-shard atau tidak dapat di-shard?
Anda dapat menandai modul (AndroidTest.xml) dengan
<option name="not-shardable" value="true" /> untuk memberi tahu harness bahwa modul tersebut
tidak boleh di-shard.
Dalam modul umum, membiarkan harness melakukan sharding pada modul Anda (perilaku default) adalah hal yang tepat untuk dilakukan. Namun, dalam beberapa kasus, Anda mungkin ingin mengganti perilaku tersebut:
- Saat penyiapan modul Anda mahal:
Sharding modul akan menghasilkan persiapan (menginstal APK, mengirim file, dll.) yang mungkin dijalankan sekali per perangkat yang terlibat. Jika penyiapan modul Anda panjang dan mahal serta tidak layak direplikasi dibandingkan dengan runtime pengujian, Anda harus menandai modul sebagai tidak dapat di-shard.
- Saat jumlah pengujian dalam modul Anda rendah:
Sharding modul akan menyebabkan semua kasus pengujian mungkin dijalankan secara independen di perangkat yang berbeda. Hal ini terkait dengan poin pertama; jika jumlah pengujian Anda rendah, Anda mungkin akan mendapatkan satu pengujian atau tidak ada pengujian di beberapa shard, yang akan membuat langkah persiapan menjadi cukup mahal. Misalnya, menginstal APK untuk satu kasus pengujian biasanya tidak sepadan.
Pengujian instrumentasi: Jumlah maksimum shard?
Uji instrumentasi yang berjalan melalui AndroidJUnitTest tidak mengekspos ke harness berapa banyak pengujian yang merupakan bagian dari instrumentasi hingga kita benar-benar menginstal dan menjalankan APK. Operasi ini mahal dan tidak dapat dijalankan pada waktu sharding untuk semua modul yang merupakan bagian dari rangkaian.
Harness mungkin melakukan sharding berlebihan pada pengujian instrumentasi dan menghasilkan beberapa shard kosong; melakukan sharding pada pengujian instrumentasi dengan lima pengujian dalam enam shard akan menghasilkan lima shard dengan satu pengujian dan satu shard tanpa pengujian. Setiap shard ini akan memerlukan penginstalan APK yang mahal.
Jadi, jika jumlah pengujian dalam APK uji instrumentasi rendah, menandai
modul dengan <option name="not-shardable" value="true" /> akan memungkinkan
harness mengetahui bahwa sharding modul tersebut tidak sepadan.
Runner AndroidJUnitTest memiliki opsi khusus yang memungkinkannya menentukan
jumlah maksimum shard yang diizinkan untuk di-shard:
<option name="ajur-max-shard" value="5" />.
Hal ini memungkinkan Anda menentukan jumlah maksimum instrumentasi yang dapat di-shard, terlepas dari jumlah shard yang diminta di tingkat pemanggilan. Secara default, instrumentasi akan di-shard ke dalam jumlah shard yang diminta untuk pemanggilan.
Misalnya, jika APK uji instrumentasi hanya berisi dua kasus pengujian, tetapi Anda tetap ingin melakukan sharding, memiliki nilai ajur-max-shard sebesar 2 akan memastikan Anda tidak membuat shard kosong.