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 umum 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-shard atau tidak dapat di-shard?
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 harness mengelompokkan modul Anda (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:
Pembagian modul akan menyebabkan semua kasus pengujian mungkin dijalankan secara independen di perangkat yang berbeda. Hal ini berkaitan 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?
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 pengujian 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" />.
Hal ini memungkinkan Anda menentukan jumlah maksimum pershardan instrumentasi, terlepas dari jumlah shard yang diminta di tingkat pemanggilan. Secara default, instrumentasi akan di-sharding menjadi 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.