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 ingin 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 dan informasi lainnya, serta skrip helper. Ini
skrip helper Anda mungkin mencakup cara membangun, menjalankan, atau menguji project Anda.
Dalam package.json
, Anda harus menambahkan skrip bernama test
yang mendeskripsikan
cara menjalankan pengujian. Hal ini penting karena, saat menggunakan npm atau metode serupa
fitur "test" skrip memiliki arti khusus.
Skrip ini dapat hanya mengarah ke satu file yang menampilkan pengecualian—
sesuatu seperti node tests.js
—tetapi sebaiknya Anda menggunakannya untuk mengarah ke
{i>test runner<i} yang mapan.
Jika Anda menggunakan Vitest sebagai test runner,
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. Di beberapa
Vitest, defaultnya adalah menemukan semua file yang diakhiri dengan ".test.js" atau
serupa, lalu menjalankannya. Bergantung pada
{i>test runner<i} yang dipilih, perintahnya mungkin sedikit berbeda.
Kami memilih untuk menggunakan Vitest, sebuah {i>framework<i} pengujian yang semakin populer, untuk di sepanjang materi ini. Anda dapat membaca lebih lanjut tentang keputusan ini dalam Vitest sebagai runner pengujian. Namun, penting untuk diingat bahwa framework dan runner pengujian—bahkan lintas bahasa—cenderung memiliki bahasa yang sama.
Pemanggilan pengujian manual
Memicu pengujian otomatis secara manual (seperti menggunakan npm test
di
contoh sebelumnya) bisa jadi praktis saat Anda aktif mengerjakan codebase.
Menulis tes untuk fitur selagi mengembangkan fitur tersebut dapat membantu Anda mendapatkan
cara kerja fitur tersebut—ini menyentuh konsep
pengembangan berbasis pengujian (TDD).
{i>Test runner<i} biasanya akan memiliki perintah
singkat yang bisa Anda panggil untuk menjalankan beberapa atau
semua pengujian Anda, dan mungkin mode watcher
yang menjalankan ulang pengujian saat Anda menyimpan
mereka. Semua itu adalah opsi yang bermanfaat
saat mengembangkan fitur baru, dan
dirancang untuk memudahkan penulisan fitur baru, pengujian, atau keduanya
dengan masukan yang cepat. Vitest, misalnya, beroperasi dalam mode watcher secara default:
Perintah vitest
akan memantau perubahan dan menjalankan ulang pengujian yang ditemukannya. Rab
sebaiknya biarkan terbuka di jendela lain saat menulis pengujian, sehingga Anda dapat
dapatkan masukan cepat tentang pengujian selagi Anda mengembangkannya.
Beberapa runner juga memungkinkan Anda menandai pengujian sebagai only
dalam kode. Jika kode Anda
menyertakan pengujian only
, maka hanya pengujian ini yang akan dipicu saat Anda menjalankan pengujian,
membuat pengembangan pengujian menjadi lebih cepat
dan lebih mudah untuk memecahkan masalah. Bahkan jika semua
pengujian selesai dengan cepat, menggunakan only
dapat mengurangi overhead dan menghilangkan
gangguan saat menjalankan pengujian yang tidak terkait dengan fitur atau pengujian yang sedang Anda kerjakan.
Untuk proyek kecil, terutama proyek dengan hanya satu developer, Anda mungkin juga ingin mengembangkan kebiasaan menjalankan seluruh rangkaian pengujian codebase Anda secara rutin. Hal ini sangat membantu jika pengujian Anda kecil dan selesai dengan cepat (tanpa beberapa detik untuk semua pengujian) sehingga Anda dapat memastikan semuanya berhasil sebelum Anda melanjutkan.
Menjalankan pengujian sebagai bagian dari prapengiriman atau peninjauan
Banyak project memilih untuk memastikan bahwa codebase berfungsi dengan benar saat
kode tersebut akan digabungkan kembali ke cabang main
-nya. Jika Anda baru
mengenal pengujian, tetapi
telah berkontribusi terhadap proyek {i>open source<i}, Anda mungkin telah memperhatikan
bagian dari proses permintaan pull (PR) mengkonfirmasi bahwa semua pengujian proyek
yang berarti bahwa kontribusi baru Anda yang menarik tidak berdampak negatif pada
project yang sudah ada.
Jika Anda menjalankan pengujian secara lokal, repositori online project Anda (misalnya, GitHub atau layanan hosting kode lainnya) tidak akan mengetahui bahwa pengujian Anda lulus, jadi menjalankan pengujian sebagai tugas pra-pengiriman menjelaskan kepada semua kontributor bahwa semuanya berfungsi.
GitHub, misalnya, menyebutnya sebagai "pemeriksaan status" yang dapat Anda tambahkan melalui
Tindakan GitHub. GitHub Actions adalah
pada dasarnya semacam pengujian: setiap langkah harus berhasil (tidak gagal, atau menampilkan
Error
) agar tindakan diteruskan. Anda dapat menerapkan {i>Action <i}
untuk semua Humas suatu proyek,
dan sebuah project dapat mengharuskan agar Tindakan diteruskan sebelum Anda menyumbangkan kode. GitHub
tindakan Node.js default menjalankan npm test
sebagai salah satu langkahnya.
Pendekatan terhadap pengujian ini mencoba untuk memastikan codebase Anda selalu "hijau" dengan tidak menerima kode yang tidak berhasil menjalankan pengujiannya.
Menjalankan pengujian sebagai bagian dari Continuous Integration
Setelah PR ramah lingkungan Anda diterima, sebagian besar codebase menjalankan pengujian lagi berdasarkan
cabang main
project Anda, bukan PR sebelumnya. Hal ini mungkin terjadi
segera, atau secara teratur (misalnya, setiap jam atau setiap malam). Ini
hasilnya sering ditampilkan sebagai bagian dari dasbor Continuous Integration (CI) yang
menunjukkan kesiapan proyek secara keseluruhan.
Langkah CI ini mungkin tampak berlebihan, terutama untuk project dengan codebase kecil— pengujian yang lulus selama peninjauan, sehingga pengujian tersebut harus lulus setelah perubahan dilakukan. Namun, ini tidak selalu benar! Pengujian Anda mungkin gagal tiba-tiba, bahkan setelah berhasil yang memberikan hasil ramah lingkungan. Beberapa alasannya antara lain:
- Beberapa perubahan diterima "sekaligus", terkadang dikenal sebagai kondisi {i>ras<i}, dan mereka saling mempengaruhi dengan cara yang halus dan belum teruji.
- Pengujian Anda tidak dapat direproduksi atau "tidak stabil" kode — keduanya bisa meneruskan
dan gagal tanpa mengubah kode.
- Hal ini mungkin terjadi jika Anda bergantung pada sistem di luar codebase Anda. Untuk
proxy, bayangkan pengujian jika
Math.random() > 0.05
—hal ini akan gagal secara acak 5% sepanjang waktu.
- 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 pada setiap PR, seperti end-to-end pengujian (selengkapnya tentang hal ini ada di jenis pengujian otomatis), dan mereka dapat menembus batas waktu tanpa selalu ada pemberitahuan.
Tidak satu pun dari masalah ini yang tidak mungkin untuk diatasi, tetapi perlu disadari bahwa pengujian, dan pengembangan perangkat lunak secara umum, tidak akan pernah sama persis sains.
Selingan saat melakukan roll back
Jika pengujian dijalankan sebagai bagian dari continuous integration, dan bahkan saat pengujian dijalankan sebagai bagian dari pemeriksaan status, mungkin saja build akan berwarna "merah" status, atau status lain yang berarti pengujian gagal. Seperti yang disebutkan sebelumnya, hal ini bisa terjadi karena berbagai alasan, termasuk kondisi race saat pengujian pengiriman, atau pengujian yang tidak stabil.
Untuk proyek yang lebih kecil, naluri Anda mungkin adalah memperlakukannya sebagai krisis! Hentikan segala sesuatunya, mengembalikan atau mengembalikan perubahan yang melanggar, dan kembali ke keadaan yang baik. Hal ini dapat menjadi pendekatan yang valid, tetapi penting untuk diingat bahwa pengujian (dan software secara umum) adalah cara untuk mencapai tujuan, bukan tujuan dalam itu sendiri. Tujuan Anda mungkin adalah untuk membuat perangkat lunak, bukan untuk lulus semua pengujian. Sebagai gantinya, Anda dapat melakukan peluncuran maju dengan menindaklanjuti perubahan yang dapat menyebabkan gangguan dengan perubahan yang memperbaiki pengujian yang gagal.
Di sisi lain, Anda mungkin telah melihat, atau mengerjakan, proyek-proyek besar yang ada dalam keadaan rusak yang terus-menerus. Atau lebih buruk lagi, proyek besar memiliki hasil tes yang tidak stabil yang cukup sering istirahat untuk menyebabkan kelelahan alarm pada pengembang. Ini sering kali menjadi masalah eksistensial yang harus dipecahkan oleh para pemimpin: ini tes bahkan mungkin dimatikan karena mereka dianggap sebagai "menghalangi jalan pengembangan aplikasi".
Tidak ada solusi cepat untuk hal ini, tetapi hal ini dapat membantu Anda menjadi lebih percaya diri dalam menulis tes (peningkatan keterampilan), dan untuk mengurangi ruang lingkup tes (penyederhanaan) sehingga kegagalannya bisa lebih mudah diidentifikasi. Peningkatan jumlah pengujian komponen atau pengujian integrasi (selengkapnya tentang jenis di Jenis pengujian pengujian) dapat memberikan kepastian yang lebih meyakinkan daripada satu pengujian menyeluruh besar yang sulit dikelola dan dilakukan semuanya sekaligus.
Resource
Menguji pemahaman Anda
Apa nama skrip khusus yang digunakan npm dan program serupa dicari saat menguji?