Resource nonaktif Espresso

Resource nonaktif mewakili operasi asinkron yang hasilnya memengaruhi ke operasi selanjutnya di pengujian UI. Dengan mendaftarkan resource nonaktif menggunakan Espresso, Anda bisa memvalidasi operasi asinkron ini dengan lebih andal saat menguji aplikasi Anda.

Mengidentifikasi kapan resource nonaktif diperlukan

Espresso menyediakan serangkaian kemampuan sinkronisasi. Ini Namun, karakteristik dari kerangka kerja hanya berlaku untuk operasi yang mengirimkan pesan di MessageQueue, seperti subclass dari View yang menggambar kontennya di layar.

Karena Espresso tidak mengetahui operasi asinkron lainnya, termasuk yang berjalan di thread latar belakang, Espresso tidak dapat menyediakan sinkronisasi yang lebih tinggi dalam situasi tersebut. Agar Espresso mengetahui yang berjalan lama, Anda harus mendaftarkan masing-masing operasi tersebut sebagai resource nonaktif.

Jika Anda tidak menggunakan resource nonaktif saat menguji hasil resource aplikasi pekerjaan asinkron, Anda mungkin mendapati diri Anda harus menggunakan salah satu mengikuti solusi yang buruk untuk meningkatkan pengujian Anda keandalan:

  • Menambahkan panggilan ke Thread.sleep(). Jika Anda menambahkan penundaan buatan ke pengujian, perlu waktu lebih lama untuk selesai dieksekusi, dan pengujian Anda terkadang masih gagal saat dijalankan pada perangkat yang lebih lambat. Selain itu, penundaan ini tidak diskalakan dengan baik, karena aplikasi Anda mungkin harus melakukan pekerjaan asinkron yang lebih memakan waktu dalam rilis mendatang.
  • Mengimplementasikan wrapper percobaan ulang, yang menggunakan loop untuk memeriksa berulang kali apakah aplikasi Anda masih menjalankan pekerjaan asinkron hingga waktu tunggu habis. Meskipun jika Anda menentukan jumlah percobaan ulang maksimum dalam pengujian, setiap eksekusi ulang akan resource sistem, terutama CPU.
  • Menggunakan instance CountDownLatch, yang memungkinkan satu atau beberapa thread menunggu sampai sejumlah operasi tertentu yang dieksekusi di thread lain sudah lengkap. Objek ini mengharuskan Anda untuk menentukan durasi waktu tunggu; jika tidak, aplikasi bisa jadi diblokir tanpa batas waktu. Kait menambah kerumitan yang tidak perlu pada kode, sehingga pemeliharaan menjadi lebih sulit.

Espresso memungkinkan Anda menghilangkan solusi yang tidak bisa diandalkan dari pengujian dan sebagai gantinya, daftarkan pekerjaan asinkron aplikasi Anda sebagai resource nonaktif.

Kasus penggunaan umum

Saat melakukan operasi yang serupa dengan contoh berikut dalam pengujian, sebaiknya gunakan resource nonaktif:

  • Memuat data dari internet atau sumber data lokal.
  • Membuat koneksi dengan database dan callback.
  • Mengelola layanan, baik menggunakan layanan sistem atau instance IntentService.
  • Menjalankan logika bisnis yang kompleks, seperti transformasi bitmap.

Mendaftarkan resource nonaktif sangat penting saat operasi ini mengupdate UI yang kemudian divalidasi oleh pengujian Anda.

Contoh implementasi resource nonaktif

Daftar berikut menjelaskan beberapa contoh implementasi resource nonaktif yang dapat Anda integrasikan ke dalam aplikasi:

CountingIdlingResource
Mempertahankan penghitung tugas aktif. Ketika penghitungnya nol, yang terkait resource dianggap tidak ada aktivitas. Fungsi ini sangat mirip dengan Semaphore. Pada umumnya, implementasi ini memadai untuk mengelola pekerjaan asinkron aplikasi Anda selama pengujian.
UriIdlingResource
Mirip dengan CountingIdlingResource, tapi penghitung harus nol selama periode waktu tertentu sebelum resource dianggap tidak ada aktivitas. Periode tunggu tambahan ini memakan waktu berturut-turut permintaan jaringan, tempat aplikasi di thread Anda mungkin membuat segera setelah menerima respons atas permintaan sebelumnya.
IdlingThreadPoolExecutor
Implementasi kustom ThreadPoolExecutor yang melacak jumlah total tugas yang sedang berjalan dalam thread yang dibuat Google Cloud. Class ini menggunakan CountingIdlingResource ke mempertahankan penghitung tugas aktif.
IdlingScheduledThreadPoolExecutor
Implementasi kustom ScheduledThreadPoolExecutor. Hal ini memberikan fungsionalitas dan kapabilitas sebagai IdlingThreadPoolExecutor kelas, tetapi juga dapat melacak tugas-tugas yang dijadwalkan di masa mendatang atau dijadwalkan untuk dilaksanakan secara berkala.

Membuat resource nonaktif sendiri

Saat menggunakan resource nonaktif dalam pengujian aplikasi, Anda mungkin perlu menyediakan manajemen resource atau logging kustom. Dalam kasus tersebut, implementasi yang tercantum di bagian sebelumnya mungkin tidak cukup. Jika demikian, Anda dapat perluas salah satu implementasi resource nonaktif ini atau buat sendiri.

Jika mengimplementasikan fungsi resource nonaktif Anda sendiri, pertahankan hal berikut yang terbaik praktik terbaik, terutama yang pertama:

Panggil transisi ke status nonaktif di luar pemeriksaan nonaktif.
Setelah aplikasi tidak ada aktivitas, panggil onTransitionToIdle() di luar setiap implementasi isIdleNow(). Dengan begitu, Espresso tidak memerlukan pemeriksaan kedua yang tidak perlu untuk menentukan apakah resource nonaktif tidak ada aktivitas.

Cuplikan kode berikut mengilustrasikan rekomendasi ini:

Kotlin

fun isIdle() {
    // DON'T call callback.onTransitionToIdle() here!
}

fun backgroundWorkDone() {
    // Background work finished.
    callback.onTransitionToIdle() // Good. Tells Espresso that the app is idle.

    // Don't do any post-processing work beyond this point. Espresso now
    // considers your app to be idle and moves on to the next test action.
}

Java

public void isIdle() {
    // DON'T call callback.onTransitionToIdle() here!
}

public void backgroundWorkDone() {
    // Background work finished.
    callback.onTransitionToIdle() // Good. Tells Espresso that the app is idle.

    // Don't do any post-processing work beyond this point. Espresso now
    // considers your app to be idle and moves on to the next test action.
}
Daftarkan resource nonaktif sebelum memerlukannya.

Manfaat sinkronisasi yang terkait dengan resource nonaktif hanya berlaku setelah pemanggilan pertama Espresso terhadap resource tersebut, Metode isIdleNow().

Daftar berikut menunjukkan beberapa contoh properti ini:

  • Jika Anda mendaftarkan resource nonaktif dalam metode yang dianotasi dengan @Before, resource nonaktif diterapkan di baris pertama setiap pengujian.
  • Jika Anda mendaftarkan resource nonaktif di dalam pengujian, resource nonaktif berlaku selama tindakan berbasis Espresso berikutnya. Perilaku ini masih akan terjadi meskipun tindakan berikutnya berada dalam pengujian yang sama dengan pernyataan yang mendaftarkan resource nonaktif.
Batalkan pendaftaran resource nonaktif setelah selesai menggunakannya.

Untuk menghemat resource sistem, Anda harus segera membatalkan pendaftaran resource nonaktif karena Anda tidak membutuhkannya lagi. Misalnya, jika Anda mendaftarkan resource nonaktif dalam metode yang dianotasikan dengan @Before, sebaiknya batalkan pendaftaran resource ini di sesuai yang dianotasikan dengan @After.

Gunakan registry nonaktif untuk mendaftarkan dan membatalkan pendaftaran resource nonaktif.

Dengan menggunakan penampung ini untuk resource nonaktif aplikasi, Anda dapat mendaftarkan dan membatalkan pendaftaran resource nonaktif berulang kali sesuai kebutuhan dan tetap mengamati performa perilaku model.

Pertahankan hanya status aplikasi sederhana dalam resource nonaktif.

Misalnya, resource nonaktif yang Anda implementasikan dan daftarkan tidak boleh berisi referensi ke objek View.

Mendaftarkan resource nonaktif

Espresso menyediakan class container tempat Anda dapat menempatkan nonaktif aplikasi Google Cloud Platform. Kelas ini, disebut IdlingRegistry, adalah artefak mandiri yang memberikan overhead minimal ke aplikasi Anda. Kelas juga memungkinkan Anda untuk mengambil langkah-langkah berikut guna meningkatkan pemeliharaan:

  • Membuat referensi ke IdlingRegistry, bukan resource nonaktif yang ada di dalamnya, dalam pengujian aplikasi Anda.
  • Mempertahankan perbedaan dalam kumpulan resource nonaktif yang Anda gunakan untuk setiap varian build.
  • Menentukan resource nonaktif di layanan aplikasi Anda, bukan di UI komponen yang mereferensikan layanan tersebut.

Mengintegrasikan resource nonaktif ke dalam aplikasi

Meskipun Anda bisa menambahkan resource nonaktif ke aplikasi dengan beberapa cara, satu secara khusus mempertahankan enkapsulasi untuk aplikasi Anda sambil tetap memungkinkan Anda untuk menentukan operasi tertentu yang diwakili oleh resource nonaktif tertentu.

Saat menambahkan resource nonaktif ke aplikasi, kami sangat merekomendasikan untuk menempatkan logika resource nonaktif dalam aplikasi itu sendiri dan hanya melakukan pendaftaran dan operasi pembatalan pendaftaran di pengujian Anda.

Meskipun Anda menciptakan situasi yang tidak biasa menggunakan antarmuka khusus pengujian di kode produksi dengan mengikuti pendekatan ini, Anda bisa menggabungkan resource nonaktif kode yang sudah Anda miliki, untuk mempertahankan ukuran APK dan jumlah metode aplikasi Anda.

Pendekatan alternatif

Jika Anda memilih untuk tidak memiliki logika resource nonaktif dalam produksi aplikasi ada beberapa strategi integrasi yang layak lainnya:

  • Membuat varian build, seperti build Gradle produk ragam aplikasi, dan hanya menggunakan resource nonaktif dalam build debug aplikasi.
  • Gunakan framework injeksi dependensi seperti Dagger untuk menginjeksikan aplikasi yang tidak ada aktivitas grafik dependensi resource ke dalam pengujian Anda. Jika Anda menggunakan Dagger 2, injeksi itu sendiri harus berasal dari subkomponen.

  • Mengimplementasikan resource nonaktif dalam pengujian aplikasi, dan mengekspos bagian tersebut dalam implementasi aplikasi Anda yang perlu disinkronkan dalam pengujian.

    Perhatian: Meskipun keputusan desain ini tampaknya membuat referensi mandiri ke resource nonaktif, hal ini juga memecah enkapsulasi di semua aplikasi kecuali aplikasi yang paling sederhana.

Referensi lainnya

Untuk informasi selengkapnya tentang menggunakan Espresso dalam pengujian Android, lihat referensi berikut.

Contoh