Menggunakan dummy pengujian di Android

Saat menguji elemen atau sistem elemen, Anda melakukannya secara terpisah. Misalnya, untuk menguji ViewModel, Anda tidak perlu memulai emulator dan meluncurkan UI karena tidak (atau tidak seharusnya) bergantung pada framework Android.

Namun, subjek yang sedang diuji mungkin bergantung pada subjek lain agar dapat berfungsi. Misalnya, ViewModel mungkin bergantung pada repositori data agar dapat berfungsi.

Jika Anda perlu memberikan dependensi ke subjek yang sedang diuji, praktik umum adalah membuat duplikat pengujian (atau objek pengujian). Pengujian ganda adalah objek yang terlihat dan bertindak sebagai komponen dalam aplikasi Anda, tetapi dibuat dalam pengujian Anda untuk memberikan perilaku atau data tertentu. Keuntungan utamanya adalah membuat pengujian Anda lebih cepat dan lebih sederhana.

Jenis double pengujian

Ada berbagai jenis double pengujian:

Palsu	Pasangan pengujian yang memiliki implementasi class yang "berfungsi", tetapi diterapkan dengan cara yang membuatnya baik untuk pengujian, tetapi tidak cocok untuk produksi. Contoh: database dalam memori. Fake tidak memerlukan framework tiruan dan bersifat ringan. Format ini lebih disarankan.
Tiruan	Test double yang berperilaku seperti yang Anda programkan dan memiliki ekspektasi tentang interaksinya. Simulasi akan gagal dalam pengujian jika interaksinya tidak sesuai dengan persyaratan yang Anda tentukan. Simulasi biasanya dibuat dengan framework tiruan untuk mencapai semua ini. Contoh: Memverifikasi bahwa metode dalam database dipanggil tepat satu kali.
Konfirmasi	Test double yang berperilaku seperti yang Anda program, tetapi tidak memiliki ekspektasi tentang interaksinya. Biasanya dibuat dengan framework tiruan. Palsu lebih disukai daripada stub untuk memudahkan.
Dummy	Pasangan pengujian yang diteruskan tetapi tidak digunakan, seperti jika Anda hanya perlu memberikannya sebagai parameter. Contoh: fungsi kosong yang diteruskan sebagai callback klik.
Mata-mata	Wrapper di atas objek nyata yang juga melacak beberapa informasi tambahan, mirip dengan tiruan. Mereka biasanya dihindari untuk menambah kerumitan. Oleh karena itu, rekayasa palsu lebih disukai daripada mata-mata.
Bayangan	Palsu digunakan di Robolectric.

Perhatian: Ada definisi yang bertentangan, bergantung pada sumbernya. Sumber yang komprehensif adalah Mocks aren't Stubs oleh Martin Fowler.

Catatan: Saat menggunakan library atau framework, hubungi penulis untuk mengetahui apakah mereka menyediakan infrastruktur pengujian yang didukung secara resmi, seperti objek palsu, yang dapat Anda andalkan dengan andal.

Contoh penggunaan palsu

Misalkan Anda ingin menguji unit ViewModel yang bergantung pada antarmuka yang disebut UserRepository dan mengekspos nama pengguna pertama ke UI. Anda dapat membuat duplikat pengujian palsu dengan menerapkan antarmuka dan menampilkan data yang diketahui.

object FakeUserRepository : UserRepository {
    fun getUsers() = listOf(UserAlice, UserBob)
}

val const UserAlice = User("Alice")
val const UserBob = User("Bob")

UserRepository palsu ini tidak perlu bergantung pada sumber data lokal dan jarak jauh yang akan digunakan versi produksi. File ini berada dalam set sumber pengujian dan tidak akan dikirim bersama aplikasi produksi.

Gambar 1: Dependensi palsu dalam pengujian unit.

Pengujian berikut memverifikasi bahwa ViewModel mengekspos nama pengguna pertama ke tampilan dengan benar.

@Test
fun viewModelA_loadsUsers_showsFirstUser() {
    // Given a VM using fake data
    val viewModel = ViewModelA(FakeUserRepository) // Kicks off data load on init

    // Verify that the exposed data is correct
    assertEquals(viewModel.firstUserName, UserAlice.name)
}

Mengganti UserRepository dengan palsu mudah dilakukan dalam pengujian unit, karena ViewModel dibuat oleh penguji. Namun, mengganti elemen arbitrer dalam pengujian yang lebih besar dapat menjadi tantangan.

Mengganti komponen dan injeksi dependensi

Jika pengujian tidak memiliki kontrol atas pembuatan sistem yang sedang diuji, penggantian komponen untuk duplikat pengujian menjadi lebih rumit dan mengharuskan arsitektur aplikasi Anda mengikuti desain yang dapat diuji.

Pengujian besar dan menyeluruh pun bisa mendapatkan manfaat dari penggunaan ganda pengujian, seperti pengujian UI berinstrumen yang menavigasi seluruh alur penggunaan penuh di aplikasi Anda. Dalam hal ini, Anda mungkin perlu membuat pengujian yang hermetik. Pengujian hermetis menghindari semua dependensi eksternal, seperti mengambil data dari internet. Hal ini akan meningkatkan keandalan dan performa.

Gambar 2: Pengujian besar yang mencakup sebagian besar aplikasi dan memalsukan data jarak jauh.

Anda dapat mendesain aplikasi untuk mencapai fleksibilitas ini secara manual, tetapi sebaiknya gunakan framework injeksi dependensi seperti Hilt untuk mengganti komponen di aplikasi Anda pada waktu pengujian. Lihat Panduan pengujian Hilt.

Catatan: Di Android, Anda juga dapat menggunakan framework Robolectric, yang menyediakan jenis pengujian ganda khusus, yang disebut bayangan.

Langkah berikutnya

Halaman Strategi pengujian menunjukkan cara meningkatkan produktivitas menggunakan berbagai jenis pengujian.