Jenis otomatisasi CI

Berikut adalah beberapa bentuk otomatisasi umum yang mungkin ingin Anda gunakan dalam sistem CI.

Tugas dasar

  • Build:Dengan mem-build project dari awal, Anda memastikan bahwa perubahan baru dikompilasi dengan benar dan semua library serta alat saling kompatibel.

  • Pemeriksaan lint atau gaya: Ini adalah langkah opsional tetapi direkomendasikan. Saat Anda menerapkan aturan gaya dan melakukan analisis statis, peninjauan kode dapat menjadi lebih ringkas dan terfokus.

  • Pengujian lokal atau sisi host: Pengujian ini berjalan di mesin lokal yang menjalankan build. Di Android, biasanya ini adalah JVM, sehingga cepat dan andal. Pengujian ini juga mencakup uji Robolectric.

Pengujian berinstrumen

Pengujian yang berjalan di emulator atau perangkat fisik memerlukan beberapa penyediaan, yang menunggu perangkat untuk booting atau terhubung dan operasi lain yang menambah kompleksitas.

Ada beberapa opsi untuk menjalankan uji instrumentasi pada CI:

  • Perangkat yang Dikelola Gradle dapat digunakan untuk menentukan perangkat yang akan digunakan (misalnya "emulator Pixel 2 di API 27") dan menangani penyediaan perangkat.
  • Sebagian besar sistem CI dilengkapi dengan plugin pihak ketiga (juga disebut "tindakan", "integrasi", atau "langkah") untuk menangani emulator Android.
  • Delegasikan pengujian berinstrumen ke farm perangkat seperti Firebase Test Lab. Farmasi perangkat digunakan karena keandalannya yang tinggi dan dapat berjalan di emulator atau perangkat fisik.

Pengujian regresi performa

Untuk memantau performa aplikasi, sebaiknya gunakan library benchmark. Otomatisasi uji performa selama pengembangan memerlukan perangkat fisik untuk memastikan hasil pengujian yang konsisten dan realistis.

Menjalankan benchmark dapat memerlukan waktu lama, terutama jika Anda memiliki cakupan kode dan perjalanan pengguna yang tinggi yang Anda tolok ukurnya. Daripada menjalankan semua benchmark untuk setiap fitur atau commit gabungan, pertimbangkan untuk menjalankannya sebagai bagian dari build pemeliharaan terjadwal secara rutin, seperti build setiap malam.

Memantau performa

Anda dapat memantau regresi performa menggunakan pengaturan langkah. Pengepasan langkah menentukan jendela berkelanjutan dari hasil build sebelumnya yang Anda bandingkan dengan build saat ini. Pendekatan ini menggabungkan beberapa hasil benchmark menjadi satu metrik khusus regresi. Anda dapat menerapkan penyesuaian langkah untuk mengurangi derau selama pengujian regresi.

Tindakan ini akan mengurangi terjadinya positif palsu (PP) yang dapat terjadi saat waktu benchmark lambat untuk satu build, lalu melakukan normalisasi lagi.

Menguji pemeriksaan regresi cakupan

Cakupan pengujian adalah metrik yang dapat membantu Anda dan tim memutuskan apakah pengujian sudah cukup mencakup perubahan. Namun, seharusnya ini bukan satu-satunya indikator. Salah satu praktik yang umum dilakukan adalah menyiapkan pemeriksaan regresi yang gagal atau menampilkan peringatan saat cakupan turun relatif terhadap cabang dasar.