Tambahkan alat praktis ini ke gudang senjata Anda
Pernahkah Anda bertanya pada diri sendiri bagaimana cara menguji front end suatu aplikasi? Pada artikel ini, kami akan menguraikan pengujian visual yang merupakan kebalikan dari pengujian perilaku. Apakah mungkin untuk memvalidasi visual secara otomatis? Bukankah itu membutuhkan manusia?
Ya, itu mungkin dan sepenuhnya otomatis! Ini akan menangkap semua regresi visual dan memberikan manfaat tambahan seperti etalase untuk anggota tim baru.
Mari kita lihat regresi seperti apa yang terjadi.
Secara matematis ini salah tetapi ditampilkan dengan baik. Tes perilaku dapat mencegah bug semacam ini. Misalnya, jika Anda menggunakan JavaScript, Anda dapat menulis tes seperti di bawah ini.
Sekarang, mari kita lihat regresi visual.
Dalam hal ini, tanda sama dengan diputar dengan buruk. Ini adalah regresi visual yang mungkin disebabkan oleh modifikasi yang cakupannya tidak terlalu luas.
Mari kita lihat cara mencegahnya.
Pengujian Cuplikan
Pengujian visual menggunakan kembali teknik terkenal yaitu pengujian snapshot yang juga disebut master emas.
Teknik ini terdiri dari beberapa langkah berurutan :
- Memotret keadaan saat ini yang akan menjadi referensi
- Membuat perubahan kode
- Memotret keadaan baru
- Membandingkan keadaan referensi dengan keadaan baru
- Menerima perubahan hanya jika perbedaannya sesuai dengan yang diharapkan
Pengujian snapshot dapat dilakukan dengan teknik yang berbeda. Misalnya, pengembang web dapat menjepret DOM untuk melihat dampak kode. Jika Anda ingin mengetahui lebih banyak tentang topik ini saya sarankan membaca Dokumentasi Jest.
Pengujian Visualmerender kode dan mengambil tangkapan layar. Ini adalah kasus khusus pengujian snapshot yang menyimpan status sebagai gambar.
Mari kita lihat cara mengambil tangkapan layar UI secara otomatis untuk melihat regresi visual di masa mendatang.
Rendering
Apa pun teknologi front-endnya, selalu ada mesin yang bertanggung jawab untuk rendering. Ini akan mengambil kode sebagai masukan dan menghasilkan visual sebagai keluaran.
Untuk pengembangan web, mesinnya adalah browser. Ini menafsirkan HTML, CSS, dan JS untuk menggambar visual.
Jika Anda menggunakan Flutter, renderingnya lebih kompleks karena Anda menargetkan platform yang berbeda. Akibatnya, rendering dibagi menjadi dua bagian utama. Mesin generik ditulis dalam C/C++ dan bagian penyematnya berisi hal-hal khusus platform. Untuk informasi lebih lanjut, Anda dapat membaca dokumentasi ini.
Ide di balik pengujian visual adalah memanggil mesin rendering melalui API dan menyimpan visual sebagai gambar.
Beberapa teknologi front-end memiliki alat yang melakukan panggilan API untuk kita. Misalnya, Flutter menyediakan fitur bawaan yang memungkinkan kita menulis Tes Visual (juga dikenal sebagai Tes Emas). Saat menjalankan pengujian, Flutter akan menyebut dirinya mesin rendering.
Untuk pengembangan web, tidak ada fitur bawaan seperti di Flutter. Faktanya, ada banyak browser sehingga ada beberapa teknik rendering. Cara termudah untuk melakukannya adalah dengan menggunakan Selenium sebagai jembatan dengan browser Anda. Ini akan menyediakan API standar untuk mengambil tangkapan layar dari halaman yang dirender.
Sekarang setelah Anda mengetahui cara mengambil snapshot kode yang dirender ke dalam gambar secara otomatis, mari kita lihat cara membandingkan dua gambar untuk menemukan perbedaannya.
Membandingkan gambar
Referensi dan gambar baru memiliki dimensi yang sama karena kami membuatnya dengan alat yang sama. Sebagai konsekuensinya, kita dapat menggunakan pendekatan yang sederhana. Sebuah gambar dapat dilihat sebagai array byte 2 dimensi. Kami mengulangi setiap bit dan membandingkannya satu per satu. Jika bytenya berbeda, kami menandai posisi saat ini.
Sekarang Anda mengetahui konsep inti pengujian visual: mengambil gambar, merender, dan membandingkan gambar. Mari kita bicara tentang masalah utamanya.
Memberikan ketidakkonsistenan
Kode yang sama dapat menghasilkan visual yang berbeda. Misalnya, aplikasi web terlihat berbeda tergantung pada browsernya. Meskipun Anda menggunakan mesin yang sama, Anda mungkin mendapatkan hasil yang berbeda. Beberapa penyebab dapat menjelaskan hal ini. Anda dapat menggunakan mesin yang sama tetapi versinya tidak sama, memiliki kebijakan yang telah diinstal sebelumnya, atau menggunakan sistem operasi yang berbeda (selengkapnya tentang Rendering Font).
Inkonsistensi kecil ini sangat buruk bagi kerja tim. Tes dapat lulus untuk satu anggota tim tetapi gagal untuk anggota tim lainnya. Dalam hal ini, Anda tidak dapat mempercayai pengujian Anda, pengujian tersebut tidak berguna.
Solusinya adalah menerima perbedaan berdasarkan ambang batas. Misalnya, Anda dapat menetapkan ambang batas yang hanya menerima perbedaan 1% dari referensi. Menemukan ambang batas yang tepat bersifat eksperimental. Semakin tinggi ambang batasnya, semakin sedikit Anda akan menangkap regresi dan semakin kecil ambang batasnya, semakin banyak pengujian yang gagal karena ketidakkonsistenan. Inilah mengapa saya merekomendasikan untuk melihat solusi ini sebagai pilihan terakhir.
Untuk mengatasi masalah ini, tim Flutter telah menemukan solusi menarik. Anda dapat merender kode Flutter Anda dengan kotak berwarna, bukan blok teks. Hal ini memungkinkan rendering yang sama di setiap platform. Trik ini dimungkinkan karena semua platform berbagi mesin rendering yang sama.
Jika Anda mempraktikkan pengembangan web, solusi mudahnya adalah dengan menggunakan SaaS seperti Chromatic yang akan mengambil tangkapan layar pada platform yang sama.
Terakhir, Anda dapat memanfaatkan virtualisasi sendiri menggunakan buruh pelabuhan. Anda harus menggunakan gambar buruh pelabuhan yang berisi mesin yang merender aplikasi.
Sekarang setelah Anda mengetahui cara mengatasi ketidakkonsistenan rendering, mari kita bahas tentang manfaat tambahan pengujian visual.
Keuntungan tambahan
Jika Anda berlatih review kode, sebagai reviewer Anda akan dapat melihat visual yang dihasilkan oleh kode tersebut. Selain itu, sebagian besar platform Git menyediakan alat untuk memeriksa perbedaan antar gambar sehingga Anda dapat menambahkan komentar pada gambar ketika Anda melihat adanya perubahan yang mencurigakan.
Juga, Anda akan memiliki etalase aplikasi Anda. Ini menarik untuk menerima anggota tim baru.
Terakhir, Anda akan dapat melihat perubahan visual seiring berjalannya waktu. Ini bagus ketika Anda mencari alasan atau kapan sesuatu telah berubah.
Keterbatasan
Sebelumnya kita telah membicarakan masalah rendering namun ada batasan lain.
Anda tidak dapat menguji animasi dengan pengujian visual. Semua alat yang tersedia yang disebutkan akan membekukan animasi Anda sebelum mengambil tangkapan layar apa pun. Oleh karena itu, jika Anda membuat perubahan pada animasi, Anda tidak akan didukung.
Tes visual lambat dibandingkan dengan tes unit klasik. Tes tersebut berada di urutan kedua, sedangkan tes visual berada di urutan milidetik. Akibatnya, putaran umpan balik Anda akan lebih lambat.
Kesimpulan
Jangan salah paham. Pengujian Visual bukanlah solusi terbaik. Itu tidak menggantikan praktik pengujian lain seperti pengujian perilaku. Anda dapat melihatnya sebagai alat lain di kotak peralatan Anda. Selain itu, ia memiliki beberapa keterbatasan yang perlu Anda waspadai seperti memberikan ketidakkonsistenan.
Anda yakin dan ingin mencoba pengujian visual pada proyek Anda? Saya akan segera merilis panduan praktis untuk pengembang web. Anda dapat mengikuti saya untuk lebih banyak artikel semacam ini.
Terakhir, jika Anda melatih TDD dengan tes perilaku, Anda dapat melakukan hal yang sama dengan tes visual Anda. Ini disebut Pengembangan Berbasis Pengujian Visual (VTDD). Untuk lebih lanjut, lihat Artikel berwarna ini.
