Tempat pengujian dijalankan

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.
• 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

• Apa Manfaat Melakukan Bangunan Malam

Menguji pemahaman Anda