Halaman ini menjelaskan hal yang dapat disesuaikan untuk modul suite
(AndroidTest.xml) melalui sharding dan mendapatkan performa kecepatan terbaik selama
eksekusi berkelanjutan di lab. Kami akan mencoba menjelaskan opsi tersebut secara
generik dengan alasan penggunaannya.
Saat menjalankan suite secara terus-menerus di lab, suite biasanya di-shard di beberapa perangkat untuk mengurangi waktu penyelesaian secara keseluruhan. Harness biasanya mencoba menyeimbangkan waktu eksekusi setiap shard untuk meminimalkan waktu penyelesaian secara 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-sharding atau tidak dapat di-sharding?
Anda dapat memberi tag pada modul (AndroidTest.xml) dengan
<option name="not-shardable" value="true" /> untuk memberi tahu harness bahwa modul tersebut
tidak boleh di-shard.
Dalam modul standar, membiarkan memanfaatkan sharding modul (perilaku default) adalah hal yang tepat untuk dilakukan. Namun dalam beberapa kasus, Anda mungkin ingin mengganti perilaku tersebut:
- Jika penyiapan modul Anda mahal:
Pembagian modul akan menghasilkan persiapan (menginstal APK, mendorong file, dll.) yang mungkin berjalan satu kali per perangkat yang terlibat. Jika penyiapan modul Anda lama dan mahal serta tidak sebanding untuk direplikasi dibandingkan dengan runtime pengujian, Anda harus memberi tag pada modul sebagai tidak dapat di-shard.
- Jika jumlah pengujian di modul Anda rendah:
Dengan sharding modul, semua kasus pengujian mungkin akan dieksekusi secara independen di perangkat yang berbeda. Hal ini berkaitan dengan poin pertama. Jika jumlah pengujian Anda rendah, Anda mungkin hanya perlu melakukan satu pengujian atau tidak melakukan pengujian di beberapa shard, sehingga setiap langkah persiapan akan menjadi cukup mahal. Menginstal APK untuk satu kasus pengujian biasanya tidak sepadan.
Uji instrumentasi: Sudah mencapai batas jumlah shard?
Pengujian instrumentasi yang berjalan melalui AndroidJUnitTest tidak mengekspos ke harness jumlah 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 suite.
Harness mungkin melakukan sharding berlebih pada uji instrumentasi dan berakhir dengan beberapa shard kosong; melakukan sharding pada uji 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, pemberian tag pada
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" />.
Dengan begitu, Anda dapat menentukan berapa kali instrumentasi dapat di-sharding, terlepas dari jumlah shard yang diminta di tingkat pemanggilan. Secara default, instrumentasi akan di-sharding ke dalam jumlah shard yang diminta untuk pemanggilan.
Misalnya, jika APK pengujian instrumentasi Anda hanya berisi dua kasus pengujian, tetapi
Anda masih ingin membuat shard, memiliki nilai ajur-max-shard 2 akan memastikan
Anda tidak membuat shard kosong.