Apa itu Pengujian Modul? Definisi, Contoh

⚡ Ringkasan Cerdas

Pengujian modul memeriksa subprogram, subrutin, kelas, dan prosedur secara individual, bukan program yang telah dirakit, sehingga cacat muncul di dalam blok kode kecil yang mudah dipahami, di mana cacat tersebut tetap mudah ditemukan dan diperbaiki dengan biaya rendah.

🎯 Tujuan: Tujuannya adalah untuk mengungkap kesalahan dalam sebuah modul, bukan untuk menunjukkan bahwa modul tersebut berfungsi.
⚪ Orientasi: Teknik ini sebagian besar bersifat white box, dilengkapi dengan kasus black box yang diambil dari spesifikasi.
⏩ Paralelisme: Beberapa modul dapat diuji secara bersamaan, yang memperpendek jangka waktu pengujian secara keseluruhan.
🔗 Dua metode: Modul-modul tersebut digabungkan secara bertahap, selangkah demi selangkah, atau secara non-bertahap dalam satu kali proses.
🧰 Perancah: Driver menyediakan data uji ke sebuah modul, sementara stub bertindak sebagai pengganti modul yang dipanggilnya.
🆚 Kepemilikan: Penguji menulis pengujian modul setelah pengkodean, sedangkan pengembang menulis pengujian unit selama pengkodean.
⚠️ Tantangan: Pekerjaan yang tidak bertahap, kesalahan pemahaman terhadap test double, dan seringnya proses debugging menghabiskan sebagian besar upaya.

Baca Selengkapnya

Apa itu Pengujian Modul?

Pengujian modul Pengujian modul adalah jenis pengujian perangkat lunak yang memeriksa subprogram, subrutin, kelas, atau prosedur individual dalam suatu program. Alih-alih menguji seluruh program perangkat lunak sekaligus, pengujian modul merekomendasikan pengujian blok penyusun program yang lebih kecil.

Pengujian modul sebagian besar berorientasi pada white box. Tujuan pengujian modul bukanlah untuk menunjukkan fungsi modul yang benar, tetapi untuk menunjukkan adanya kesalahan di dalamnya. Pembalikan ini penting: pengujian yang tidak menemukan apa pun hanya sedikit mengkonfirmasi kesalahan, sedangkan pengujian yang mengungkap cacat telah menyelesaikan tugasnya.

Pengujian tingkat modul juga memungkinkan paralelisme untuk diperkenalkan ke dalam proses pengujian, karena hal ini menciptakan peluang untuk menguji beberapa modul secara bersamaan alih-alih menunggu hingga proses build selesai sepenuhnya.

Mengapa melakukan Pengujian Modul

Pengujian modul direkomendasikan karena hal itu mengubah aspek ekonomi dari deteksi kerusakan.

Kemungkinan mengidentifikasi kesalahan atau bug dalam bagian-bagian program yang lebih kecil menjadi lebih tinggi.
Beberapa modul dapat diuji secara bersamaan, dan oleh karena itu pendekatan ini mendukung pengujian paralel.
Kompleksitas pengujian dapat dikelola dengan mudah, karena setiap modul dianalisis secara terpisah.
Cacat yang ditemukan di dalam salah satu modul adalah tracMampu menangani sejumlah kecil kode, sehingga waktu debugging berkurang tajam.

Bagaimana cara melakukan Pengujian Modul?

Merancang a Kasus cobaan Ini adalah segmen penting dari pengujian modul. Saat merancang kasus uji untuk pengujian modul, seorang penguji harus mempertimbangkan dua hal.

Spesifikasi modul
Kode sumber modul

Analisis logika modul dengan menggunakan satu atau lebih dari kotak putih metode, dan kemudian melengkapi kasus uji ini dengan menerapkan kotak hitam metode untuk spesifikasi modul. Nilai realistis sama pentingnya dengan jalur yang dipilih, jadi persiapkanlah. data uji bersamaan dengan kasus-kasus tersebut, bukan setelahnya.

Setelah kasus uji dirancang, langkah selanjutnya adalah menggabungkan modul-modul untuk pengujian. Metode yang digunakan adalah salah satu dari berikut ini: inkremental atau tidak inkremental Metode.

Metode non-inkremental — semua modul diuji secara independen. Pertama-tama, semua modul digabungkan, kemudian seluruh program diuji.
Metode inkremental — setiap modul diuji terlebih dahulu dan kemudian secara bertahap ditambahkan ke koleksi yang telah diuji. Proses ini melakukan pengujian ulang secara bertahap.
Dalam pengujian bertahap terdapat dua pendekatan, Perintahkan ke bawah ke bawah ke atas pengujian.
Untuk menjalankan modul dengan data yang dipilih, diperlukan driver untuk menyediakan data uji, memantau eksekusi, dan menangkap hasilnya.

Pilihan antara kedua metode tersebut merupakan pertimbangan antara upaya penyiapan dan kemudahan diagnosis.

Aspek	Metode inkremental	Metode non-inkremental
Kombinasi	Satu modul per satu, ditambahkan ke koleksi yang telah diuji.	Semua modul digabungkan, kemudian diuji bersama.
Perancah dibutuhkan	Lebih banyak pengemudi dan tiket, ditulis secara bertahap.	Jumlah test double lebih sedikit, karena modul yang sebenarnya sudah tersedia.
Isolasi kesalahan	Kuat — titik kegagalan terletak pada modul yang baru saja ditambahkan	Lemah — kegagalan bisa berasal dari mana saja
Paling cocok untuk	Bangunan besar dengan banyak modul yang saling berinteraksi.	Program kecil dengan sedikit modul dan kopling rendah.

Driver dan Stub dalam Pengujian Modul

Driver yang disebutkan di atas adalah salah satu bagian dari sebuah pasangan. Karena modul yang sedang diuji jarang berada di bagian atas atau bawah rantai panggilan, penguji mengganti kode dummy untuk apa pun yang hilang di kedua sisinya.

sopir — menggantikan modul pemanggil di atas modul yang sedang diuji. Ia menyediakan data uji, memanggil modul, memantau eksekusi, dan menangkap hasilnya. Pengujian bottom-up bergantung pada driver, karena modul yang lebih rendah siap sebelum modul yang lebih tinggi.
Potongan — menggantikan modul yang dipanggil di bawah modul yang sedang diuji. Ia menerima panggilan dan mengembalikan respons tetap yang diketahui sehingga modul yang sedang diuji dapat menyelesaikan jalurnya. Pengujian dari atas ke bawah bergantung pada stub, karena modul yang lebih tinggi siap terlebih dahulu.

Sebuah contoh kasus yang telah dikerjakan membuat pemasangan tersebut menjadi konkret. Jika modul perhitungan pembayaran telah selesai sementara layar checkout yang memanggilnya belum, pengemudi akan memasukkan serangkaian total pesanan ke dalam modul dan mencatat apa yang dikembalikan. Jika layanan pencarian pajak yang dipanggil oleh modul tersebut juga belum selesai, sebuah data sementara akan mengembalikan tarif pajak tetap sehingga perhitungan tetap berjalan. Kedua bagian kerangka kerja tersebut tidak dikirim; keduanya dibuang setelah modul sebenarnya tiba, itulah sebabnya kesalahpahaman tentang test double tercantum kemudian sebagai tantangan yang berulang.

Contoh Tip untuk Pengujian Modul

Berikut beberapa tips yang perlu dipertimbangkan sebelum melakukan pengujian modul.

RevTinjau kasus uji sebelum menggunakannya.
Hindari kebingungan mengenai sumber perbedaan tersebut.
Gunakan alat pengujian otomatis.
Periksa variabel-variabel yang seharusnya tidak diubah.
Tukar modul antar penguji untuk menghindari pengujian mandiri.
Gunakan kembali kasus uji tersebut.

Kiat kelima ini memiliki bobot lebih besar daripada yang terlihat dari panjangnya. Pengembang yang hanya menguji modul yang baru saja ditulis akan mengulangi asumsi yang sama yang menyebabkan cacat tersebut, jadi merotasi modul antar orang adalah salah satu cara termurah untuk meningkatkan kualitas.

Pengujian Unit vs Pengujian Modul

Kedua istilah tersebut digunakan secara bergantian di banyak tim, namun kepengarangan dan cakupannya berbeda.

Pengujian Modul	Pengujian Unit
Tes modul adalah kumpulan tes yang ditulis oleh penguji setelah beberapa kode ditulis oleh pengembang	Tes unit adalah kumpulan tes yang ditulis oleh pengembang selama proses pengembangan perangkat lunak.
Pengujian modul dapat melibatkan penggabungan pengujian unit.	Pengujian unit dapat menguji unit secara terpisah.

Pengujian Modul vs Pengujian Komponen vs Pengujian Integrasi

Pengujian modul juga berada di samping dua level yang berdekatan yang mudah membingungkan. Tabel tersebut memisahkan keduanya berdasarkan apa yang sedang diuji dan siapa yang biasanya melaksanakannya.

Aspek	Pengujian modul	Pengujian komponen	Tes integrasi
Sedang diuji	Satu subprogram, kelas, atau prosedur	Satu komponen mandiri beserta dependensi langsungnya.	Antarmuka antara modul gabungan
Pemilik biasa	Penguji, setelah kode ditulis	penguji	Penguji integrasi
Perancah	Pengemudi dan tiket	Stub untuk dependensi eksternal	Jumlah pemain pengganti dalam tes semakin berkurang.
Cacat terungkap	Kesalahan logika di dalam modul	Kesalahan perilaku pada komponen	Kesalahan antarmuka dan pengiriman data

Dalam penggunaan sehari-hari pengujian komponen dan pengujian modul seringkali dianggap sebagai aktivitas yang sama, sementara tes integrasi Proses dimulai hanya setelah setiap modul individu telah lulus secara terpisah.

Tantangan dalam Pengujian Modul

Inilah tantangan yang paling sering dihadapi tim ketika pengujian modul diperkenalkan.

Pengujian non-inkremental membutuhkan lebih banyak pekerjaan — menggabungkan semuanya terlebih dahulu berarti satu kegagalan saja dapat membuat penguji harus mengulang seluruh program.
Kesalahpahaman tentang tes ganda — sebuah stub yang mengembalikan nilai yang tidak realistis menghasilkan run hijau yang tidak membuktikan apa pun.
Debugging tes sering — Kode kerangka kerja memiliki kekurangannya sendiri, dan waktu yang dihabiskan untuk memperbaiki driver adalah waktu yang tidak dihabiskan untuk menguji modul tersebut.
Perlu memahami kodenya — Orientasi kotak putih berarti penguji yang tidak dapat membaca modul tersebut tidak dapat merancang kasus yang bermakna untuknya.

Pertanyaan Umum Demo Slot

Keluarga xUnit mencakup sebagian besar bahasa, dengan pustaka mocking yang menyediakan stub dan alat cakupan yang menunjukkan jalur mana yang telah dicapai. Pilihan tersebut mengikuti bahasa modul, bukan tingkat pengujian.

Sebuah model membaca kode sumber modul, menghitung cabang-cabangnya, dan mengusulkan sebuah kasus untuk masing-masing cabang, termasuk nilai batas yang seringkali terlewatkan oleh proses manual. RevTinjauan tetap diperlukan, karena kasus yang dihasilkan menegaskan apa yang dilakukan kode tersebut, bukan apa yang dipersyaratkan oleh spesifikasi.

Ya, dan perancah (scaffolding) adalah tempat di mana asisten semacam itu bekerja paling baik, karena driver atau stub adalah kode berulang dengan bentuk yang diketahui. Nilai yang dikembalikan masih membutuhkan keputusan manusia, karena stub yang tampak masuk akal dapat menyembunyikan cacat yang sedang dicari.

Cukup dengan memastikan bahwa setiap cabang dan setiap batasan dalam modul telah dicoba setidaknya sekali. Target persentase saja menyesatkan, karena cakupan pernyataan yang tinggi masih dapat menyebabkan seluruh hasil keputusan tidak dicoba.

Setelah modul dikompilasi dan sebelum antarmuka-antarmuka di dalamnya dijalankan bersama-sama, ini adalah tingkat pengujian pertama yang diterapkan pada kode yang telah dikirim. Oleh karena itu, cacat yang terdeteksi di sini tidak pernah mencapai tahap integrasi atau sistem.

Ikuti kode yang sudah ada. Pendekatan top-down cocok untuk proyek di mana logika kontrol ditulis terlebih dahulu dan modul yang lebih rendah dibuat sebagai kerangka sementara; pendekatan bottom-up cocok untuk proyek di mana modul utilitas ditempatkan terlebih dahulu dan driver memanggilnya.

Modul tersebut berhasil dikompilasi, spesifikasinya tersedia, dependensinya ada atau sudah disiapkan, dan data uji sudah siap. Memulai tanpa spesifikasi akan mengubah latihan ini menjadi deskripsi kode.

Pengujian tidak pernah dapat membuktikan bahwa suatu modul tidak memiliki cacat, hanya membuktikan bahwa modul tersebut berhasil melewati berbagai kasus yang dicoba. Oleh karena itu, merancang pengujian yang bertujuan untuk merusak modul akan memberikan lebih banyak informasi daripada merancang pengujian yang diharapkan berhasil.