Pengujian otomatis biasanya dapat dijalankan dengan menjalankan skrip secara manual, atau menggunakan helper dari framework pengujian, yang sering disebut test runner, untuk menemukan dan menjalankan pengujian. Namun, Anda mungkin tidak selalu perlu menjalankan skrip secara manual. Ada sejumlah cara untuk menjalankan pengujian yang dapat memberikan masukan dan kepercayaan pada titik yang berbeda selama siklus proses pengembangan.
Skrip prasyarat
Project web biasanya memiliki file konfigurasi—file package.json-nya—yang
disiapkan oleh npm, pnpm, Bun, atau yang serupa. File konfigurasi ini berisi dependensi project Anda dan informasi lainnya, serta skrip helper. Skrip
helper ini dapat mencakup cara membangun, menjalankan, atau menguji project Anda.
Dalam package.json, Anda harus menambahkan skrip bernama test yang menjelaskan cara menjalankan pengujian. Hal ini penting karena, saat menggunakan npm atau alat serupa, skrip"test" memiliki arti khusus.
Skrip ini dapat hanya mengarah ke satu file yang menampilkan pengecualian—
misalnya, node tests.js—tetapi sebaiknya gunakan untuk mengarah ke
runner pengujian yang sudah mapan.
Jika Anda menggunakan Vitest sebagai runner pengujian, file
package.json akan terlihat seperti berikut:
{
"name": "example-project",
"scripts": {
"start": "node server.js",
"test": "vitest --run"
}
}
Menjalankan npm test dengan file ini akan menjalankan kumpulan pengujian default Vitest satu kali. Pada Vitest, defaultnya adalah menemukan semua file yang diakhiri dengan ".test.js" atau yang serupa, lalu menjalankannya. Bergantung pada
runner pengujian yang Anda pilih, perintahnya mungkin sedikit berbeda.
Kami telah memilih untuk menggunakan Vitest, framework pengujian yang makin populer, untuk contoh dalam kursus ini. Anda dapat membaca selengkapnya tentang keputusan ini di Vitest as a test runner. Namun, penting untuk diingat bahwa framework dan runner pengujian—bahkan di seluruh bahasa—cenderung memiliki bahasa sehari-hari yang sama.
Pemanggilan pengujian manual
Memicu pengujian otomatis secara manual (seperti menggunakan npm test pada
contoh sebelumnya) dapat dilakukan saat Anda aktif mengerjakan codebase.
Menulis pengujian untuk fitur saat mengembangkan fitur tersebut dapat membantu Anda memahami
cara kerja fitur tersebut—hal ini menyentuh konsep
pengembangan berbasis pengujian (TDD).
Runner pengujian biasanya memiliki perintah singkat yang dapat Anda panggil untuk menjalankan beberapa atau semua pengujian, dan mungkin mode watcher yang menjalankan ulang pengujian saat Anda menyimpannya. Semua opsi ini adalah opsi bermanfaat saat mengembangkan fitur baru, dan opsi ini
dirancang untuk memudahkan penulisan fitur baru, pengujiannya, atau keduanya, semuanya
dengan masukan cepat. Misalnya, vitest beroperasi dalam mode watcher secara default:
perintah vitest akan memantau perubahan dan menjalankan ulang pengujian yang ditemukannya. Sebaiknya
biarkan pengujian ini tetap terbuka di jendela lain saat Anda menulis pengujian, sehingga Anda bisa
mendapatkan masukan cepat tentang pengujian saat mengembangkannya.
Beberapa runner juga memungkinkan Anda menandai pengujian sebagai only di kode. Jika kode Anda menyertakan pengujian only, hanya pengujian ini yang akan dipicu saat Anda menjalankan pengujian, sehingga pengembangan pengujian menjadi lebih cepat dan lebih mudah untuk diselesaikan. Meskipun semua pengujian selesai dengan cepat, penggunaan only dapat mengurangi overhead dan menghilangkan gangguan saat menjalankan pengujian yang tidak terkait dengan fitur atau pengujian yang sedang Anda kerjakan.
Untuk project kecil, terutama project dengan satu developer saja, Anda mungkin juga ingin membiasakan menjalankan seluruh rangkaian pengujian codebase secara rutin. Hal ini sangat membantu jika pengujian Anda kecil dan selesai dengan cepat (tidak lebih dari beberapa detik untuk semua pengujian), sehingga Anda dapat memastikan semuanya berfungsi sebelum melanjutkan.
Menjalankan pengujian sebagai bagian dari prapengiriman atau peninjauan
Banyak project memilih untuk mengonfirmasi bahwa codebase berfungsi dengan benar saat
kode digabungkan kembali ke cabang main. Jika baru melakukan pengujian, tetapi
telah berkontribusi pada project open source sebelumnya, Anda mungkin melihat
bagian proses permintaan pull (PR) yang mengonfirmasi bahwa semua pengujian project
lulus, yang berarti bahwa kontribusi baru yang menarik tersebut tidak berdampak negatif terhadap
project yang ada.
Jika Anda menjalankan pengujian secara lokal, repositori online project (misalnya, GitHub atau layanan hosting kode lainnya) tidak akan mengetahui bahwa pengujian Anda lulus, jadi menjalankan pengujian sebagai tugas pra-pengiriman akan memperjelas bagi semua kontributor bahwa semuanya berfungsi.
Misalnya, GitHub menyebutnya sebagai "pemeriksaan status" yang dapat ditambahkan melalui
GitHub Actions. Action GitHub
pada dasarnya adalah semacam pengujian: setiap langkah harus berhasil (bukan gagal, atau menampilkan
Error) agar tindakan dapat lulus. Anda dapat menerapkan Action ke semua PR untuk suatu project,
dan sebuah project dapat mengharuskan bahwa Actions diteruskan sebelum Anda mengontribusi kode. Tindakan Node.js default GitHub menjalankan npm test sebagai salah satu langkahnya.
Pendekatan untuk pengujian ini berupaya memastikan codebase Anda selalu "hijau" dengan tidak menerima kode yang tidak berhasil menjalankan pengujiannya.
Menjalankan pengujian sebagai bagian dari Continuous Integration
Setelah PR hijau Anda diterima, sebagian besar codebase menjalankan pengujian lagi berdasarkan cabang main project Anda, bukan PR sebelumnya. Hal ini mungkin terjadi secara langsung, atau secara teratur (misalnya, setiap jam atau setiap malam). Hasil ini sering ditampilkan sebagai bagian dari dasbor Continuous Integration (CI) yang menampilkan kondisi project secara keseluruhan.
Langkah CI ini mungkin tampak berlebihan, terutama untuk project dengan codebase kecil, yaitu pengujian yang lulus selama peninjauan, sehingga harus lulus setelah perubahan diterapkan. Namun, hal ini tidak selalu benar. Pengujian Anda mungkin gagal secara tiba-tiba, bahkan setelah berhasil menghasilkan hasil yang berwarna hijau. Beberapa alasannya antara lain:
- Beberapa perubahan diterima "sekaligus", terkadang dikenal sebagai kondisi race, dan saling memengaruhi satu sama lain dengan cara yang belum teruji.
- Pengujian Anda tidak dapat direproduksi, atau menguji kode yang "tidak stabil"—keduanya bisa lulus dan gagal tanpa perubahan kode.
- Hal ini mungkin terjadi jika Anda bergantung pada sistem di luar codebase Anda. Untuk proxy, bayangkan pengujian jika
Math.random() > 0.05—tindakan ini akan gagal secara acak 5% dari waktu pengujian.
- Hal ini mungkin terjadi jika Anda bergantung pada sistem di luar codebase Anda. Untuk proxy, bayangkan pengujian jika
- Beberapa pengujian terlalu mahal atau mahal untuk dijalankan di setiap PR, seperti pengujian end-to-end (selengkapnya tentang hal ini dibahas dalam jenis pengujian otomatis), dan pengujian tersebut dapat rusak seiring waktu tanpa selalu memberi peringatan.
Tak satu pun dari masalah ini yang tidak mungkin diatasi, tetapi perlu disadari bahwa pengujian, dan pengembangan software secara umum, tidak akan pernah menjadi ilmu pasti.
Jeda saat melakukan roll back
Jika pengujian dijalankan sebagai bagian dari continuous integration, dan meskipun pengujian dijalankan sebagai bagian dari pemeriksaan status, build mungkin berakhir dalam status "merah", atau status lain yang berarti pengujian gagal. Seperti yang disebutkan sebelumnya, hal ini dapat terjadi karena sejumlah alasan, termasuk kondisi race saat pengiriman pengujian, atau pengujian yang tidak stabil.
Untuk proyek yang lebih kecil, naluri Anda mungkin memperlakukannya sebagai krisis. Hentikan semuanya, roll back atau kembalikan perubahan yang mengganggu, dan kembali ke status baik yang diketahui. Ini dapat menjadi pendekatan yang valid, tetapi penting untuk diingat bahwa pengujian (dan software secara umum) adalah cara untuk mencapai tujuan, bukan objektif itu sendiri. Tujuan Anda mungkin adalah menulis software, bukan membuat semua pengujian lulus. Sebagai gantinya, Anda dapat meluncur maju dengan menindaklanjuti perubahan yang dapat menyebabkan gangguan dengan perubahan lain yang memperbaiki pengujian yang gagal.
Di sisi lain, Anda mungkin pernah melihat, atau mengerjakan, project besar yang berada dalam kondisi rusak terus-menerus. Atau lebih buruk lagi, project besar memiliki pengujian tidak stabil yang cukup sering rusak sehingga menyebabkan kelelahan alarm pada developer. Ini sering kali menjadi masalah eksistensial yang harus dipecahkan oleh pemimpin: pengujian ini bahkan dapat dinonaktifkan karena dianggap "menghalangi pengembangan".
Tidak ada perbaikan cepat untuk hal ini, tetapi akan membantu menjadikan ujian menulis lebih percaya diri (meningkatkan keterampilan), dan mengurangi cakupan pengujian (penyederhanaan) sehingga kegagalan dapat lebih mudah diidentifikasi. Peningkatan jumlah pengujian komponen atau pengujian integrasi (lebih lanjut tentang jenis dalam Jenis pengujian otomatis) dapat memberikan keyakinan lebih daripada satu pengujian menyeluruh besar yang sulit dikelola dan mencoba melakukan semuanya sekaligus.
Referensi
Menguji pemahaman Anda
Apa nama skrip khusus yang dicari npm dan program serupa saat melakukan pengujian?