Panduan Pemula untuk Menguji: Kesalahan Menangani Kasus Tepi

Saat membuat perangkat lunak yang rumit, apa pun bahasanya, Anda mulai memperhatikan pola dalam kebiasaan pengujian Anda. Masalah serupa yang tampak serupa akan muncul di berbagai platform atau proyek. Terlepas dari apakah Anda sedang membuat demo daftar tugas sederhana lainnya untuk ceramah atau merancang back-end komprehensif untuk startup PaaS, pola umum yang sama mulai muncul.

Ada enam kasus yang harus diuji yang akan menyoroti sejumlah masalah yang mengejutkan. Ini tidak dimaksudkan untuk menjadi komprehensif, atau rangkaian pengujian lengkap mereka sendiri. Sebaliknya, mereka adalah subset paradigma pengujian umum yang mudah diingat yang dapat diterapkan ke bahasa, kerangka kerja, atau lingkungan apa pun.

Kasus-kasus ini segera berguna dalam dua aspek rutinitas pengkodean harian: men-debug masalah tertentu saat muncul, dan dalam pembuatan rangkaian pengujian untuk basis kode. Pengujian tersebut dimaksudkan sebagai bentuk pengujian abstrak dan generik yang akan menjelaskan beberapa masalah paling umum yang dihadapi developer junior.

Ini hanya akan berguna secara tidak langsung dalam pemrograman fungsional. Pemrograman fungsional menghindari banyak jenis bug paling sederhana yang diuraikan di bawah ini. Apa pun itu, sebaiknya ingat kasus batas abstrak semacam ini, karena kasus tersebut memberikan pagar pembatas terhadap praktik buruk dalam kode.

Keenam tes tersebut adalah sebagai berikut:

  • Nol
  • Satu
  • Dua
  • Dua hingga maks-1
  • maks
  • maks + 1

Meskipun ini adalah kasus batas, nilainya ada pada apa yang mereka wakili. Sambil memastikan bahwa pengujian Anda mencakup semua fungsionalitas program Anda, Anda harus menjaga pengujian Anda tetap sederhana dengan sesedikit mungkin bakat.

Nol

Nol digunakan untuk menandakan segala bentuk masukan nol, apakah itu tidak terdefinisi, null, array kosong, atau hanya angka aktual 0. Bentuk bug yang paling umum dan sederhana adalah mereferensikan nilai Nol, dan selalu mengandung pengujian. Cukup uji fungsi, titik akhir, atau unggah dengan masukan Nol, dan verifikasi bahwa berfungsi seperti yang diharapkan.

Satu

Satu, seperti Zero, adalah bentuk paling dasar dari pengujian tunggal yang umum. Fungsi ini diuji dengan input normal pertama yang valid. Ini paling berguna untuk pengujian regresi. Di iterasi kode di masa mendatang, pengujian ini akan dengan cepat menunjukkan apakah program (atau proses) beroperasi seperti yang diharapkan.

Satu pengujian memberi Anda dasar untuk sukses, apakah itu autentikasi yang berhasil pada titik akhir admin, unggahan file yang valid, atau modifikasi larik yang benar.

Dua

Dua tidak hanya tentang menguji indeks array 2, atau apakah algoritme Anda bekerja dengan 2 input. Ini juga mencakup apa yang terjadi ketika Anda menjalankan kode yang sama dua kali.

Jika seseorang membuat permintaan DELETE HTTP dua kali berturut-turut ke sumber daya yang sama, apa yang terjadi? Jika fungsi sortir dengan pembanding kustom dipanggil dua kali berturut-turut, apakah berfungsi seperti yang diharapkan?

Dua adalah angka yang menarik, karena ini pertama kalinya kode valid yang berfungsi saat dipanggil sekali dapat menunjukkan efek samping pada eksekusi berulang. Lakukan sedikit perubahan pada fungsi yang telah kami uji di atas.

Itu bermuara pada modifikasi negara, dan memahami perilaku suatu fungsi. Jika yang kita miliki hanyalah nama fungsi maka kode ini berperilaku persis seperti yang diantisipasi. Anda memiliki variabel yang disebut 0, Anda memanggil fungsi setVarToOne, dan kemudian Anda menyatakan bahwa itu sama dengan satu.

Sekilas, ini berperilaku persis seperti yang diharapkan. Namun, mengujinya dengan gagasan Dua dalam pikiran akan menyoroti masalah yang lebih dalam dengan kode. Anda akan mengujinya dengan memanggilnya dua kali, dan menegaskan bahwa dalam kedua kasus, mVar sama dengan 1.

Dua hingga maks-1

Dua hingga maks-1 adalah pemeriksaan kewarasan. Ini sangat mirip dengan One test, tetapi ada perbedaan yang halus. Ini harus menjadi kasus penggunaan rata - rata - bukan yang paling sederhana atau paling langsung, atau paling mudah untuk dibaca. Hanya kasus penggunaan rata-rata yang mungkin tidak terlalu sederhana, tetapi itu cukup umum .

Max

Max cukup mudah: ini hanya menguji batas aplikasi Anda, terutama di sekitar konstanta maks yang ditentukan.

Jika Anda memiliki penerapan daftar tertaut sederhana, Anda mungkin membayangkan bahwa Anda memiliki jumlah sisipan yang diizinkan yang tampaknya tak terbatas. Pada kenyataannya, ada batas atas - apakah itu INT_MAX, jumlah deskriptor file yang dapat dibuka OS Anda, atau hanya jumlah memori atau ruang disk yang dialokasikan untuk program Anda.

Dalam beberapa keadaan, Max mungkin tampak seperti tes yang mustahil karena tidak ada max yang diketahui untuk apa pun yang Anda uji. Tujuannya dalam kasus ini, bagaimanapun, adalah sifat lain: untuk menguji aplikasi Anda.

Misalnya, ada kemungkinan bagian tertentu dari data yang dikirimkan pengguna dikurangi dan diteruskan melalui fungsi hingga mencapai loop yang Anda tentukan. Jika data ini, katakanlah, INT_MAX, mungkin perlu waktu yang tidak dapat diabaikan untuk menyelesaikan kode Anda. Lebih buruk lagi, ini mungkin membuat kode Anda menjadi tidak berhenti. Ini bisa menjadi masalah halus yang hanya muncul setelah kode Anda mulai diproduksi, jadi penting untuk mengetahuinya selama fase pengujian.

Max + 1

Max + 1 adalah tes yang sebagian besar digunakan untuk memverifikasi standar atau aturan yang diterapkan oleh programmer. Ini melibatkan pengujian apa pun hingga batas teoretisnya + epsilon.

Ini bisa bermanifestasi sebagai masalah array di luar batas, kesalahan satu per satu, kesalahan bilangan bulat overflow, atau masalah lain apa pun yang terjadi saat Anda mencapai batas fungsi atau program Anda.

Jika Anda memiliki ukuran unggahan file maksimal 2mb, coba unggah file berukuran 2mb + 1b. Jika Anda memiliki batasan jumlah entri dalam katalog pengguna, pastikan bahwa verifikasi terjadi di sisi klien dansisi server.

Kesimpulan

Seperti yang disebutkan di atas, ini bukanlah gambaran lengkap tentang apa yang seharusnya menjadi rutinitas debugging atau pengujian Anda. Ini hanya memberikan dasar umum yang solid yang harus melampaui rangkaian pengujian atau kerangka kerja tertentu.

Tes ini biasanya dilihat sebagai kasus batas atau tepi, tetapi tes tersebut dapat memunculkan kepalanya yang buruk di tempat yang tidak segera terlihat.