Menulis skrip uji otomatis itu mudah. Menulis yang masih mempertahankan kegunaannya enam bulan kemudian adalah bagian yang sulit. Banyak skrip uji ditulis, berjalan hijau sekali, lalu perlahan-lahan membusuk, rusak karena perubahan yang tidak terkait, tidak menguji apa pun yang berarti, dan melatih tim untuk mengabaikan build merah. Skrip uji yang baik itu presisi, terisolasi, dan tahan lama.
Panduan ini mencakup apa itu skrip uji otomatis, struktur yang membuatnya dapat diandalkan, dua cara untuk menulis skrip uji API, dan pembangunan langkah demi langkah di Apidog.
Apa itu skrip uji otomatis
Skrip uji otomatis adalah serangkaian instruksi yang terdefinisi dan dapat diulang yang menguji bagian dari perangkat lunak Anda dan memeriksa hasilnya, tanpa campur tangan manusia dalam menjalankan langkah-langkahnya. Skrip mengirimkan input, melakukan tindakan, dan membandingkan hasilnya dengan ekspektasi. Jika cocok, skrip lulus. Jika tidak, skrip gagal dan melaporkan alasannya.
Skrip uji adalah bentuk yang dapat dieksekusi dari kasus uji. Kasus uji menjelaskan tujuan, input, tindakan, dan hasil yang diharapkan, dalam bahasa manusia. Skrip mengubah tujuan tersebut menjadi sesuatu yang dijalankan oleh mesin pada setiap commit. Satu kasus uji dapat menjadi satu skrip; skenario uji biasanya menjadi beberapa skrip yang dirangkai bersama.
Nilai keseluruhan dari skrip uji otomatis adalah bahwa ia berjalan dengan cara yang sama setiap saat. Itu hanya berlaku jika skrip ditulis untuk menjadi deterministik. Skrip yang bergantung pada urutan skrip lain berjalan, atau pada data yang ditinggalkan oleh eksekusi sebelumnya, bukanlah otomatisasi yang dapat diandalkan; itu adalah kerentanan yang tidak stabil.
Struktur skrip uji yang andal
Hampir setiap skrip uji yang ditulis dengan baik, dalam bahasa atau alat apa pun, mengikuti bentuk empat bagian yang sama. Ini sering disebut Arrange-Act-Assert, dengan tambahan cleanup.
Arrange (Persiapan). Siapkan semua yang dibutuhkan pengujian: data input, otentikasi, prasyarat apa pun. Skrip harus membuat keadaannya sendiri daripada mengasumsikan itu sudah ada. Jika pengujian membutuhkan pengguna, ia harus membuatnya, atau menggunakan data uji yang sudah dikenal, bukan apa pun yang kebetulan ada di database.
Act (Tindakan). Lakukan satu tindakan yang diuji. Skrip yang baik menguji satu perilaku. Mengirim permintaan, memanggil fungsi, memicu suatu peristiwa, itulah tindakannya, dan seharusnya hanya ada satu per skrip.
Assert (Verifikasi). Periksa hasil terhadap ekspektasi. Ini adalah bagian yang kurang diinvestasikan oleh tim. Skrip yang hanya memverifikasi “tidak ada kesalahan yang terjadi” atau “status adalah 200” hampir tidak menguji apa pun. Verifikasi yang kuat memeriksa nilai-nilai aktual: body respons, skema, efek samping, waktu.
Cleanup (Pembersihan). Batalkan apa yang dibuat oleh skrip sehingga dapat berjalan lagi dari awal yang bersih. Skrip yang meninggalkan data uji akan akhirnya bertabrakan dengan dirinya sendiri atau dengan skrip lain.
Tiga kebiasaan memisahkan skrip yang tahan lama dari yang rapuh. Uji satu hal per skrip, sehingga kegagalan memiliki satu penyebab yang jelas. Jaga skrip tetap independen, sehingga dapat berjalan dalam urutan apa pun. Dan verifikasi nilai-nilai yang stabil, jangan pernah pada data yang volatil seperti ID yang dihasilkan atau stempel waktu, yang membuat skrip gagal tanpa alasan yang jelas.
Dua cara untuk menulis skrip uji API
Untuk pengujian API secara khusus, ada dua pendekatan umum, dan keduanya cocok untuk tim yang berbeda.
Pendekatan code-first menulis skrip uji dalam bahasa tujuan umum. Di Python, itu berarti kerangka kerja seperti pytest ditambah pustaka HTTP; di JavaScript, test runner ditambah fetch. Anda menulis permintaan, verifikasi, dan penyiapan sebagai kode aktual, dan skrip berada di repositori Anda bersama dengan aplikasi.
Pendekatan ini memberikan kontrol pemrograman penuh. Logika kompleks, fixture kustom, dan verifikasi yang tidak biasa semuanya hanyalah kode. Biayanya adalah setiap skrip adalah kode yang Anda tulis dan pelihara, tim membutuhkan keterampilan bahasa, dan banyak boilerplate, penanganan otentikasi, pembangunan permintaan, parsing respons, ditulis ulang di seluruh skrip. Ini cocok untuk tim teknik yang menginginkan pengujian versi dengan kode dan merasa nyaman memiliki pemeliharaan tersebut.
Pendekatan visual membangun skrip uji dalam alat pengujian API khusus. Anda mendefinisikan permintaan, menambahkan verifikasi dengan mengklik, dan merangkai permintaan ke dalam skenario, tanpa menulis atau memelihara kode skrip untuk kasus umum. Alat seperti Apidog mengambil rute ini.
Pendekatan ini menghilangkan boilerplate dan membuat skrip dapat dibaca oleh siapa pun di tim, tidak hanya mereka yang tahu bahasanya. Anda masih perlu menulis kode kustom untuk logika langka yang tidak dapat diungkapkan oleh pembangun visual. Ini cocok untuk tim campuran, pengujian yang dipimpin QA, dan siapa saja yang ingin memiliki suite pengujian yang berjalan cepat tanpa proyek scripting terlampir.
Keduanya tidak salah. Pertanyaan penentu adalah siapa yang memelihara skrip dan apakah mereka harus berada di repositori aplikasi. Untuk sebagian besar pengujian API, pendekatan visual memungkinkan suite yang andal berjalan lebih cepat dengan lebih sedikit pemeliharaan.
Menulis skrip uji API otomatis di Apidog
Berikut adalah alur lengkap untuk membangun skrip uji API yang tahan lama secara visual.
Langkah 1: Definisikan permintaan. Masukkan endpoint ke Apidog dari file OpenAPI atau definisikan secara langsung. Ini adalah langkah Arrange; permintaan membawa metode, path, header, dan body-nya.
Langkah 2: Tambahkan data uji. Atur payload input untuk kasus yang Anda uji. Untuk mencakup banyak input dengan satu skrip, lampirkan file CSV atau JSON sehingga skrip berjalan sekali per baris; pengujian berbasis data menggantikan selusin skrip yang hampir identik dengan satu skrip.
Langkah 3: Tulis verifikasi. Ini adalah intinya. Tambahkan pemeriksaan visual: status sama dengan kode yang diharapkan, bidang body utama ada dan memiliki nilai yang benar, respons sesuai dengan skema, waktu respons sesuai anggaran. Untuk kasus negatif, verifikasi bentuk error, bukan hanya kode kegagalan. Tahan godaan untuk memverifikasi data yang volatil.
Langkah 4: Rangkai permintaan ke dalam skenario. Alur kerja nyata melibatkan beberapa panggilan. Bangun skenario yang melakukan login, membuat sumber daya, membacanya kembali, dan menghapusnya, meneruskan nilai dari satu langkah ke langkah berikutnya. Setiap langkah adalah skrip; bersama-sama mereka menguji alur lengkap.
Langkah 5: Tambahkan logika skrip kustom hanya jika diperlukan. Untuk pemeriksaan yang tidak dapat diungkapkan oleh verifikasi visual, logika kondisional, nilai yang dihitung, perbandingan antar-permintaan, tambahkan pre- atau post-processor JavaScript. Jaga agar ini minimal; sebagian besar skrip tidak pernah membutuhkannya.
Langkah 6: Jalankan dan baca laporannya. Jalankan skenario. Apidog menjalankan setiap skrip, mengevaluasi setiap verifikasi, dan melaporkan pemeriksaan yang gagal secara tepat dengan nilai yang diharapkan dan aktual berdampingan.
Langkah 7: Otomatiskan eksekusi. Hubungkan skenario ke CI/CD sehingga berjalan pada setiap commit. Skrip uji yang hanya berjalan ketika seseorang mengingatnya tidak benar-benar otomatis. Unduh Apidog untuk membangun skenario pertama Anda.
Menjaga kesehatan skrip uji
Suite uji adalah hal yang hidup. Skrip yang sempurna saat rilis menjadi usang seiring perubahan API. Tiga praktik menjaga suite tetap dapat dipercaya.
Perbarui skrip bersamaan dengan API, bukan setelahnya. Ketika kontrak endpoint berubah, skrip harus berubah dalam commit yang sama. Skrip yang memverifikasi skema lama gagal karena alasan yang salah dan mengikis kepercayaan pada setiap skrip lainnya.
Perlakukan skrip yang tidak stabil sebagai bug nyata. Skrip yang sering lulus sebagian besar waktu lebih buruk daripada tidak ada skrip sama sekali, karena itu mengajarkan tim bahwa warna merah tidak berarti rusak. Telusuri penyebabnya, biasanya kondisi bersama atau asumsi waktu, dan perbaiki.
Tinjau skrip seperti kode produksi. Skrip dengan verifikasi yang lemah, hanya memeriksa kode 200, terlihat hijau dan terasa aman padahal hampir tidak menguji apa pun. Pembaca kedua akan menyadari hal itu.
Pertanyaan yang sering diajukan
Apa perbedaan antara kasus uji dan skrip uji? Kasus uji menjelaskan tujuan dalam bahasa manusia, input, tindakan, hasil yang diharapkan. Skrip uji adalah versi yang dapat dieksekusi yang dijalankan mesin. Kasus adalah rencana; skrip adalah implementasi.
Apakah saya perlu tahu cara membuat kode untuk menulis skrip uji otomatis? Tidak untuk pengujian API dengan alat visual. Di Apidog, Anda membangun permintaan, verifikasi, dan skenario dengan mengklik, dan menulis kode hanya untuk logika yang tidak biasa. Kerangka kerja code-first memang memerlukan keterampilan bahasa.
Mengapa skrip uji saya sering rusak? Penyebab umumnya adalah memverifikasi data yang volatil, skrip yang bergantung pada kondisi satu sama lain, dan tidak memperbarui skrip saat API berubah. Isolasi data uji, jaga skrip tetap independen, dan perbarui sesuai kontrak.
Berapa banyak verifikasi yang harus dimiliki satu skrip uji? Cukup untuk memverifikasi hasilnya secara sungguh-sungguh, biasanya status, bidang body utama, skema, dan waktu. Verifikasi kode status tunggal terlalu sedikit; itu lulus padahal responsnya salah.
Haruskah skrip uji berada di repositori aplikasi? Dengan pendekatan code-first, biasanya ya, sehingga pengujian versi dengan kode. Dengan alat visual, skrip berada di platform pengujian dan disinkronkan ke definisi API sebagai gantinya. Keduanya berfungsi; konsistensi lebih penting daripada pilihan.
Bagaimana cara menulis skrip uji sebelum API dibangun? Tulis berdasarkan desain API. Jika Anda memiliki spesifikasi OpenAPI, Anda dapat mendefinisikan permintaan dan verifikasi darinya, lalu menjalankannya terhadap mock server sampai endpoint yang sebenarnya ada. Skrip siap saat implementasi selesai.
Apa perbedaan antara skrip uji dan suite uji? Skrip uji menjalankan satu pemeriksaan. Suite uji adalah kumpulan skrip yang dikelompokkan untuk berjalan bersama, seringkali mencakup seluruh API atau fitur. Suite menjaga kumpulan skrip yang terus bertambah tetap terorganisir dan memungkinkan Anda menjalankan cakupan luas dalam satu perintah.
Berapa lama seharusnya skrip uji otomatis? Sesingkat mungkin sambil tetap melakukan empat bagian: arrange (persiapan), act (tindakan), assert (verifikasi), clean up (pembersihan). Jika skrip panjang, biasanya ia menguji lebih dari satu hal dan harus dipecah. Satu perilaku per skrip membuat kegagalan mudah didiagnosis.