Halaman ini menjelaskan apa yang dapat disesuaikan untuk modul rangkaian pengujian (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 pengujian secara terus-menerus di lab, rangkaian pengujian biasanya di-shard di beberapa perangkat untuk mengurangi waktu penyelesaian secara 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 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 umum, membiarkan harness membagi modul Anda (perilaku default) adalah hal yang tepat. Namun, dalam beberapa kasus, Anda mungkin ingin mengganti perilaku tersebut:
- Saat penyiapan modul Anda mahal:
Memecah modul akan menghasilkan persiapan (menginstal APK, mengirim file, dll.) yang mungkin dijalankan satu kali per perangkat yang terlibat. Jika penyiapan modul Anda panjang dan mahal serta tidak layak direplikasi dibandingkan dengan runtime pengujian, Anda harus menandai modul Anda sebagai tidak dapat di-shard.
- Jika jumlah pengujian dalam modul Anda rendah:
Memecah modul akan membuat semua kasus pengujian dapat dieksekusi secara independen di perangkat yang berbeda. Hal ini terkait dengan poin pertama; jika jumlah pengujian Anda sedikit, Anda mungkin akan mendapatkan satu pengujian atau tidak ada pengujian di beberapa shard, yang akan membuat langkah persiapan apa pun menjadi cukup mahal. Misalnya, menginstal APK untuk satu kasus pengujian biasanya tidak sepadan.
Uji instrumentasi: Jumlah maksimum shard?
Pengujian 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 dieksekusi pada waktu sharding untuk semua modul yang merupakan bagian dari rangkaian produk.
Harness dapat melakukan over-sharding pada uji instrumentasi dan menghasilkan 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 memerlukan penginstalan APK yang mahal.
Jadi, saat jumlah pengujian di APK pengujian 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 bagian yang diizinkan untuk dibagi:
<option name="ajur-max-shard" value="5" />.
Dengan demikian, Anda dapat menentukan jumlah maksimum waktu instrumentasi dapat di-shard, terlepas dari jumlah shard yang diminta di tingkat pemanggilan. Secara default, instrumentasi akan dibagi menjadi jumlah shard yang diminta untuk pemanggilan.
Misalnya, jika APK pengujian instrumentasi Anda hanya berisi dua kasus pengujian, tetapi Anda tetap ingin membaginya, nilai ajur-max-shard sebesar 2 akan memastikan Anda tidak membuat shard kosong.