Nama-nama yang diberikan pada berbagai jenis pengujian cenderung memiliki tema yang sama di seluruh codebase, tetapi tidak memiliki definisi yang sangat ketat. Kursus ini memberikan beberapa panduan tentang arti setiap jenis pengujian, tetapi referensi lain mungkin memberikan definisi yang berbeda.
Di halaman sebelumnya, sudah ada contoh pengujian unit dan pengujian komponen (dalam contoh kami, merujuk ke komponen React). Kita dapat menempatkan keduanya di bagian rendah pada piramida pengujian (atau bentuk lainnya!), karena keduanya memiliki kompleksitas yang rendah dan cepat dijalankan, tetapi mungkin tidak memiliki utilitas sebanyak pengujian integrasi yang lebih kompleks.
Jenis pengujian umum
Pengujian Unit
Pengujian unit memiliki cakupan terkecil. Output ini cenderung digunakan untuk menguji sebagian kecil kode, atau kode yang sepenuhnya stateless, dengan cara yang hampir matematis: jika saya memberikan input X, Y, dan Z pada kode Anda, outputnya harus A, B, dan C.
Kode dengan pengujian unit biasanya tidak akan memiliki dependensi eksternal, seperti pengambilan dari jaringan atau secara implisit menggunakan fungsi atau library lainnya. Ini adalah node pohon kode yang dapat Anda "potong" dan uji sendiri.
Meskipun pengujian unit cenderung cepat ditulis dan dijalankan, pengujian unit kecil kode mungkin saja tidak akan memberikan informasi yang berguna. Sering kali, kurangnya interaksi unit kode dengan kode lain membuat Anda lebih baik melakukan pengujian pada tingkat yang lebih tinggi untuk mengurangi risiko.
Pengujian komponen
Untuk developer web, nama "component" kelebihan beban, sering kali berarti komponen yang terlihat oleh pengguna, seperti komponen React atau komponen Web. Definisinya yang lebih umum adalah bagian pekerjaan yang dapat diuji, misalnya, class dengan dependensi eksternal. Agar diuji secara efektif, dependensi komponen ini harus ditiru atau dilewati.
Karena praktik pengembangan web modern didasarkan pada konsep komponen, pengujian komponen adalah cara praktis untuk memikirkan pengujian: misalnya, Anda dapat memutuskan bahwa setiap komponen memerlukan pengujian. Pengujian komponen juga mudah ditindaklanjuti dalam konteks saat satu developer atau tim kecil mengklaim kepemilikan yang jelas atas suatu komponen. Namun, mungkin sulit untuk meniru dependensi yang kompleks.
Pengujian integrasi
Pengujian ini cenderung menguji sekelompok kecil komponen, modul, subsistem, atau bagian penting lainnya dari kode Anda secara bersamaan untuk memastikan semuanya berfungsi dengan benar. Ini adalah definisi yang sangat samar. Untuk developer web, bayangkan bahwa kode yang Anda uji bukanlah build produksi situs yang sebenarnya (atau bahkan build yang berdekatan), tetapi masih menghubungkan berbagai komponen terkait pada sistem Anda.
Ini bahkan dapat mencakup dependensi "nyata", seperti database eksternal dalam mode
pengujian, bukan tiruan murni. Misalnya, daripada menyatakan bahwa query() akan selalu menampilkan dua entri yang sama, pengujian integrasi Anda dapat mengonfirmasi bahwa database pengujian memiliki sesuatu di dalamnya. Data itu sendiri tidak begitu penting, tetapi sekarang Anda menguji apakah database dapat terhubung dan berhasil dikueri.
Anda dapat menulis pengujian integrasi yang relatif sederhana dengan implikasi beragam yang dapat diperiksa menggunakan pernyataan, karena satu tindakan yang terhubung ke berbagai komponen dapat menyebabkan serangkaian efek yang dapat diukur.
Oleh karena itu, pengujian integrasi dapat secara efektif menunjukkan bahwa sistem yang kompleks
Anda akan berjalan sebagaimana mestinya. Namun, skrip ini mungkin sulit untuk ditulis dan dikelola,
dan dapat menimbulkan kompleksitas yang tidak perlu. Misalnya, menulis
FakeUserService untuk pengujian integrasi akan menambahkan persyaratan bahwa pengujian dan
RealUserService harus mengimplementasikan UserService.
Uji asap
Ini adalah pengujian yang harus selesai dengan sangat cepat dan menentukan apakah codebase Anda berada dalam status yang wajar. Dalam praktiknya, hal ini berarti melakukan pengujian sederhana pada kode yang memiliki efek beragam terhadap pengalaman Anda.
Misalnya, dalam aplikasi web login yang besar, hal ini dapat memastikan bahwa sistem login dan autentikasi berfungsi, karena tanpanya aplikasi tidak dapat digunakan dan pengujian lebih lanjut tidak relevan.
Pengujian smoke dapat menjadi kandidat yang baik untuk dijalankan pada skrip test package.json Anda dalam codebase berukuran besar. Pengujian manual juga dapat berfungsi seperti uji asap.
Uji regresi
Pengujian regresi adalah jenis pengujian asap yang memastikan bahwa fitur yang ada terus berfungsi, atau bahwa bug lama tidak diperkenalkan kembali, setelah rilis baru atau pengembangan fitur lainnya.
Hal ini terkait dengan konsep pengembangan yang didorong oleh pengujian (TDD). Kasus pengujian yang ditulis untuk memicu bug secara eksplisit, lalu digunakan untuk memastikan bug diperbaiki, dihitung sebagai kasus pengujian regresi, karena keberadaannya harus mencegah bug yang sama ditampilkan.
Namun, pengujian regresi dapat menjadi masalah tanpa solusi yang bagus. Istilah ini sering disebut oleh kebutuhan bisnis: saat fitur dikembangkan, fitur yang lama tidak boleh rusak. Codebase yang teruji dengan baik harus dapat mempertahankan hal ini, tetapi codebase yang sebenarnya tidak selalu sesuai dengan idealnya. Hal ini akan dibahas lebih lanjut di bagian mendatang.
Pengujian visual
Pengujian visual melibatkan pengambilan screenshot atau video status situs untuk memeriksa status baik yang diketahui (seperti screenshot sebelumnya) terhadap pengujian saat ini yang dijalankan. Umumnya, browser harus dijalankan agar dapat merender HTML, CSS, dan bagian lain dari situs.
Daripada menguji pengujian menyeluruh secara visual yang menjalankan seluruh codebase Anda, sebaiknya build "harness" HTML yang hanya merender komponen tertentu, terutama dalam berbagai ukuran layar untuk memicu UI yang responsif. Cara ini lebih kompleks daripada hanya menggunakan JSDOM atau framework serupa.
Pengujian visual yang gagal dapat menjadi sinyal yang baik dari jenis kerusakan lainnya. Namun, UI yang kompleks dapat gagal dalam pengujian visual karena alasan yang tidak terkait dengan fitur yang Anda coba uji, seperti fitur baru lainnya yang mengubah tampilan UI, atau bahkan versi OS baru yang merender emoji secara berbeda dari versi sebelumnya.
Pengujian menyeluruh
Pengujian menyeluruh sering kali berada di bagian atas piramida pengujian. Objek ini menjelaskan interaksi seluruh pengalaman dengan aplikasi web atau situs Anda, mungkin berpusat pada fitur tertentu, dan biasanya berjalan di dalam browser yang dikontrol oleh agen seperti WebdriverIO, Selenium, atau Puppeteer, yang dapat menjalankan codebase seperti yang akan di-deploy di produksi (meskipun sering disajikan di localhost).
Bergantung pada situs Anda, hal ini mungkin melibatkan login sebagai pengguna uji coba, melakukan tindakan utama, dan mengonfirmasi bahwa situs atau sistem Anda dalam status yang benar. Kami akan membahas lebih banyak contoh jenis pengujian ini di bagian selanjutnya, karena pengujian tersebut bisa sangat efektif, tetapi terkadang sulit dikelola.
Beberapa taktik untuk menyederhanakannya dapat mencakup pengurangan cakupan, atau tiruan komponen tertentu jika relevan. Misalnya, jika pengguna perlu login ke situs Anda, tetapi login bukanlah fitur yang Anda uji, Anda dapat menetapkan tanda untuk lingkungan pengujian yang memungkinkan pengontrol pengujian bertindak sebagai pengguna tanpa login atau membuat cookie terkait.
Meskipun pengujian menyeluruh dapat menjadi cara yang sangat efektif untuk melakukan pengujian di berbagai bagian codebase Anda sekaligus, pengujian berskala besar tersebut berisiko tidak stabil atau tidak dapat diandalkan karena dependensinya pada sistem eksternal. Pengujian ini juga sering kali dapat meninggalkan banyak data pengujian di database Anda jika, misalnya, setiap pengujian membuat atau mengubah entri. Mengumpulkan data yang tersisa seperti ini dapat menyulitkan untuk menentukan bagaimana pengujian gagal.
Pengujian API
Pengujian API dapat mengacu pada konfirmasi perilaku API yang disediakan software Anda, atau mengakses API dunia nyata (mungkin aktif) untuk mengonfirmasi perilakunya. Apa pun pun, hal ini cenderung menguji abstraksi antar-sistem—bagaimana sistem tersebut pada akhirnya akan berkomunikasi satu sama lain—tanpa benar-benar mengintegrasikannya bersama seperti dalam pengujian integrasi.
Pengujian ini dapat memberikan prekursor dasar untuk pengujian integrasi tanpa overhead untuk menjalankan sistem tempat Anda menguji koneksi. Namun, pengujian sistem di dunia nyata bisa tidak stabil.
Jenis lain
Ada berbagai pendekatan lain untuk pengujian yang mungkin berguna, bergantung pada sumber Anda. Berikut beberapa contoh menariknya:
- Pengujian manual.
- Pengujian penerimaan, sejenis pengujian manual yang dipopulerkan oleh {i>Agile<i}, menegaskan bahwa produk tersebut "memenuhi kebutuhan pengguna".
- Pengujian kekacauan mengacu pada proses memasukkan data acak untuk melihat apa yang terjadi, untuk memastikan situs tidak akan error jika data yang buruk dimasukkan.
- Pengujian kegagalan dengan sengaja menyimulasikan kegagalan dalam sistem yang kompleks, seperti kegagalan jaringan, untuk memastikan kode yang sedang diuji merespons dengan cara yang terkontrol.
- Pengujian build mengonfirmasi bahwa artefak build codebase dapat dibuat, dengan memeriksa apakah artefak tersebut ada atau apa kontennya. Jenis pengujian ini dapat berguna untuk memeriksa output CMS yang kompleks.
Cakupan kode
Anda dapat mengukur persentase kode Anda yang diuji oleh pengujian otomatis, dan melaporkannya sebagai statistik dari waktu ke waktu. Sebaiknya jangan menargetkan 100% cakupan kode karena dapat menyebabkan overhead yang tidak perlu serta pengujian sederhana atau yang didesain buruk yang tidak mencakup kasus penggunaan utama secara mendalam.
Cakupan itu sendiri juga dapat menjadi alat yang berguna saat menulis atau mengerjakan pengujian, terutama pengujian integrasi. Dengan menampilkan persentase atau perincian baris demi baris tentang kode yang diuji oleh satu pengujian, Anda dapat memperoleh insight tentang kode yang hilang atau yang dapat diuji berikutnya.
Referensi
Menguji pemahaman Anda
Manakah dari berikut ini yang merupakan jenis pengujian yang diketahui?