Apa itu Pengujian Unit?

Oleh: Thomas Hamilton Thomas Hamilton
Hours Updated
Pengambilan Kunci Pengujian unit memastikan setiap komponen perangkat lunak berfungsi sebagaimana mestinya, mendeteksi cacat lebih awal, dan mengurangi biaya. Dengan mengadopsi pola yang telah terbukti seperti AAA, integrasi dengan pipeline CI/CD, dan penggunaan kerangka kerja modern, tim meningkatkan kualitas, keandalan, dan kepercayaan diri kode dalam rilis.

Apa itu Unit Testing

Apa itu Pengujian Unit?

Pengujian unit adalah metode pengujian perangkat lunak di mana unit atau komponen kode individual—seperti fungsi, metode, atau kelas—diuji secara terpisah untuk memastikan semuanya berfungsi dengan benar. Tujuannya adalah untuk memvalidasi bahwa setiap bagian terkecil dari suatu aplikasi berperilaku seperti yang diharapkan tanpa ketergantungan pada sistem eksternal.

A satuan bisa sekecil fungsi tunggal atau sebesar modul kecil, tergantung pada bagaimana perangkat lunak tersebut dirancang. Prinsip utamanya adalah isolasi:sumber daya eksternal seperti basis data, API, atau sistem berkas harus ditiru atau dibuat stub sehingga pengujian hanya berfokus pada logika unit.

Misalnya, di Python:

def add (a, b): 
return a + b 
def test_add():
assert add(2, 3) == 5

Tes sederhana ini memeriksa apakah add Fungsi mengembalikan hasil yang benar. Meskipun sederhana, fungsi ini menunjukkan idenya: verifikasi logika secara independen sebelum diintegrasikan dengan sistem lainnya.

Dengan mempraktikkan pengujian unit, pengembang membuat Internet aman yang dengan cepat mendeteksi regresi, mendukung pemfaktoran ulang, dan meningkatkan pemeliharaan perangkat lunak.

Penjelasan Video Pengujian Unit

Mengapa melakukan Pengujian Unit?

Pengujian Unit penting karena pengembang perangkat lunak terkadang mencoba menghemat waktu dengan melakukan pengujian unit minimal, dan ini adalah mitos karena pengujian unit yang tidak tepat menyebabkan tingginya biaya perbaikan Cacat selama Pengujian Sistem, Pengujian Integrasi, dan bahkan Pengujian Beta setelah aplikasi selesai dibuat. Jika pengujian unit yang tepat dilakukan di awal pengembangan, maka pada akhirnya akan menghemat waktu dan biaya.

Tingkat Pengujian Unit
Tingkat Pengujian Unit

Berikut adalah alasan utama untuk melakukan pengujian unit dalam rekayasa perangkat lunak:

  • Deteksi bug dini – Masalah muncul dekat dengan tempat munculnya, sehingga perbaikan menjadi lebih cepat dan murah.
  • Peningkatan kualitas kode – Kode yang bersih dan dapat diuji sering kali menghasilkan arsitektur yang lebih baik dan lebih sedikit dependensi tersembunyi.
  • Perlindungan regresi – Pengujian unit berfungsi sebagai jaring pengaman selama proses refaktor, memastikan fitur lama tetap berfungsi.
  • Siklus pengembangan lebih cepat – Pengujian otomatis memperpendek putaran umpan balik QA dan mengurangi beban pengujian manual.
  • Kepercayaan diri tim yang lebih tinggi – Dengan cakupan pengujian unit yang kuat, pengembang menyebarkan pembaruan karena tahu pembaruan tersebut tidak akan merusak fitur yang sudah ada.

Singkatnya: pengujian unit menghemat waktu, mengurangi risiko, dan meningkatkan keandalanIni mengubah pengujian dari sekadar renungan yang menyakitkan menjadi praktik rekayasa yang proaktif.

Bagaimana Melakukan Pengujian Unit?

Alur pengujian unit yang andal bersifat prediktif, cepat, dan otomatis. Gunakan siklus enam langkah ini untuk menjaga kualitas tetap tinggi dan umpan balik cepat.

Langkah 1) Analisis Unit & Tentukan Kasus

Identifikasi perilaku terkecil yang dapat diuji. Daftar jalan bahagia, kasus tepi, dan kondisi kesalahanMemperjelas masukan/keluaran dan kondisi sebelum/sesudah.

Langkah 2) Siapkan Lingkungan Pengujian

Pilih kerangka kerja, muat perlengkapan minimal, dan mengisolasi dependensi (tiruan/rintisan/palsu). Pastikan pengaturan tetap ringan untuk menghindari pengujian yang lambat dan rapuh.

Langkah 3) Tulis Tes (Pola AAA)

Mengatur masukan dan konteks → Bertindak dengan memanggil unit → Tegas hasil yang diharapkan. Lebih mengutamakan pernyataan perilaku daripada detail implementasi internal.

# Arrange
cart = Cart(tax_rate=0.1)
# Act
total = cart.total([Item("book", 100)])
# Assert
assert total == 110

Langkah 4) Jalankan Secara Lokal & di CI

Jalankan pengujian pada mesin Anda terlebih dahulu; lalu jalankan di CI untuk pemeriksaan lingkungan yang bersih. Gagal dengan cepat; buat log yang ringkas dan mudah ditindaklanjuti.

Langkah 5) Diagnosis Kegagalan, Perbaiki, dan Refaktor

Ketika sebuah tes gagal, perbaiki kode atau pengujiannya, bukan keduanya sekaligus. Setelah hijau, lakukan refaktor dengan percaya diri—menguji perilaku penjaga.

Langkah 6) Jalankan kembali, Revlihat, dan Pertahankan

Jalankan ulang rangkaian lengkapnya. Hapus pengujian yang tidak stabil, hapus duplikasi perlengkapan, dan terapkan ambang batas cakupan tanpa memanipulasinya. Tandai tes yang lambat agar berjalan lebih jarang.

Tips Pro:

  • Pertahankan tes cepat (<200 ms masing-masing) dan independen.
  • Tes nama untuk laku (misalnya, test_total_includes_tax).
  • Perlakukan ketidakstabilan sebagai masalah; karantina, perbaiki akar permasalahannya, lalu aktifkan kembali.

ARTIKEL TERKAIT

Apa Saja Teknik Pengujian Unit yang Berbeda?

Pengujian unit paling efektif jika digabungkan teknik desain pengujian cerdas dengan tujuan cakupan yang masuk akal. Targetkan keluasan di mana hal tersebut penting, kedalaman di mana risikonya paling tinggi, dan hindari jebakan "100% atau gagal".

The Teknik Pengujian Unit secara garis besar dikategorikan menjadi tiga bagian:

  1. Pengujian kotak hitam yang melibatkan pengujian antarmuka pengguna, beserta input dan output
  2. Pengujian kotak putih melibatkan pengujian perilaku fungsional aplikasi perangkat lunak
  3. Pengujian kotak abu-abu digunakan untuk menjalankan rangkaian pengujian, metode pengujian, dan kasus pengujian, serta melakukan analisis risiko

Cakupan adalah indikator utama, bukan garis akhir. Gunakan itu untuk temukan titik buta, bukan untuk mempermainkan angka. Teknik cakupan kode yang digunakan dalam Pengujian Unit tercantum di bawah ini:

  • Cakupan Pernyataan
  • Cakupan Keputusan
  • Cakupan Cabang
  • Cakupan Kondisi
  • Cakupan Mesin Keadaan Hingga

Untuk informasi lebih lanjut tentang Cakupan Kode, lihat https://www.guru99.com/code-coverage.html

Apa Peran Mocking dan Stubbing dalam Pengujian Unit

Pengujian unit harus fokus hanya pada kode yang diuji — bukan dependensinya. Di situlah mengejek dan Rintisan bertopik masuk. "Pengujian ganda" ini menggantikan objek nyata sehingga Anda dapat mengisolasi perilaku, mengontrol input, dan menghindari pengujian yang lambat atau tidak stabil.

Mengapa Menggunakan Tes Doubles?

  • Isolasi – Uji hanya unitnya, bukan basis data, jaringan, atau sistem berkas.
  • Determinisme – Kontrol keluaran dan efek samping sehingga hasilnya konsisten.
  • Kecepatan – Pengujian berjalan dalam milidetik saat tidak menyentuh sistem eksternal.
  • Simulasi kasus tepi – Mudah meniru kesalahan (misalnya, batas waktu API) tanpa menunggu kesalahan tersebut terjadi dalam kehidupan nyata.

Rintisan bertopik

A potongan adalah pengganti yang disederhanakan yang mengembalikan respons tetap. Pengganti ini tidak merekam interaksi — hanya menyediakan data siap pakai.

Contoh (Python):

def get_user_from_db(user_id):
# Imagine a real DB call here
raise NotImplementedError()
def test_returns_user_with_stub(monkeypatch):
# Arrange: stubbed DB call
monkeypatch.setattr("app.get_user_from_db", lambda _: {"id": 1, "name": "Alice"})
# Act
user = get_user_from_db(1)
# Assert
assert user["name"] == "Alice"

Mengolok-olok

A mengejek lebih kuat: ia dapat memverifikasi interaksi (misalnya, “apakah metode ini dipanggil dengan X?”).

Contoh (JavaSkrip dengan Jest):

const sendEmail = jest.fn();
function registerUser(user, emailService) {
emailService(user.email, "Welcome!");
test("sends welcome email", () => {
// Arrange
const user = { email: "test@example.com" };
// Act
registerUser(user, sendEmail);
// Assert
expect(sendEmail).toHaveBeenCalledWith("test@example.com", "Welcome!");

});

Ini, mengejek memeriksa apakah layanan email dipanggil dengan benar — sesuatu yang tidak dapat dilakukan oleh rintisan.

Kesalahan Umum

  • Terlalu mengejek – Jika setiap kolaborator diejek, pengujian menjadi rapuh dan terikat pada detail implementasi.
  • Menguji tiruan alih-alih perilaku – Fokus pada hasil (nilai keadaan/kembali) dibandingkan interaksi jika memungkinkan.
  • Kode pengaturan bocor – Jaga tiruan/rintisan tetap ringan; gunakan alat bantu atau perlengkapan agar mudah dibaca.

Aturan Umum

  • Berhenti ketika Anda hanya membutuhkan data.
  • Mengejek saat Anda perlu memverifikasi interaksi.
  • Lebih suka yang palsu daripada yang palsu bila Anda bisa (misalnya, DB dalam memori alih-alih mengejek setiap kueri).

Intinya: Mengejek dan menjelek-jelekkan adalah aktor pendukung, bukan bintang. Gunakan mereka untuk mengisolasi unit Anda, tetapi jangan biarkan mereka membajak rangkaian pengujian.

Apa Saja Alat Pengujian Unit Umum?

Ada beberapa perangkat lunak pengujian unit otomatis yang tersedia untuk membantu pengujian unit dalam pengujian perangkat lunak. Kami akan memberikan beberapa contohnya di bawah ini:

  1. JUnit:Junit adalah alat pengujian gratis yang digunakan untuk Java Bahasa pemrograman. Alat ini menyediakan pernyataan untuk mengidentifikasi metode pengujian. Alat ini menguji data terlebih dahulu, lalu memasukkannya ke dalam potongan kode.
  2. NUnitNUnit adalah kerangka kerja pengujian unit yang banyak digunakan untuk semua bahasa .NET. NUnit merupakan alat sumber terbuka yang memungkinkan penulisan skrip secara manual. NUnit mendukung pengujian berbasis data, yang dapat dijalankan secara paralel.
  3. Unit PHPPHPUnit adalah alat pengujian unit untuk programmer PHP. Alat ini mengambil bagian-bagian kecil kode, yang disebut unit, dan menguji masing-masing unit secara terpisah. Alat ini juga memungkinkan pengembang untuk menggunakan metode asersi yang telah ditentukan sebelumnya untuk memastikan bahwa suatu sistem berperilaku dengan cara tertentu.

Itu hanyalah beberapa dari alat pengujian unit yang tersedia. Masih banyak lagi, khususnya untuk bahasa C dan Java, tetapi Anda pasti akan menemukan alat pengujian unit untuk kebutuhan pemrograman Anda, apa pun bahasa yang Anda gunakan.

Pengembangan Berbasis Uji (TDD) & Pengujian Unit

Pengujian unit dalam TDD melibatkan penggunaan kerangka kerja pengujian yang ekstensif. Kerangka kerja pengujian unit digunakan untuk membuat pengujian unit otomatis. Kerangka kerja pengujian unit tidak hanya terbatas pada TDD, tetapi juga penting. Di bawah ini, kita akan membahas beberapa hal yang dibawa TDD ke dunia pengujian unit:

  • Tes ditulis sebelum kode
  • Sangat bergantung pada kerangka pengujian
  • Semua kelas dalam aplikasi diuji
  • Integrasi yang cepat dan mudah dimungkinkan

Berikut adalah beberapa manfaat TDD:

  • Mendorong unit-unit kecil yang dapat diuji dan desain yang sederhana.
  • Mencegah rekayasa berlebihan; Anda hanya membangun apa yang dituntut pengujian.
  • Menyediakan jaring pengaman hidup untuk para refaktor.

Saran Ahli: Pilih TDD saat Anda menginginkannya umpan balik desain yang ketat pada tingkat kode dan kemajuan yang cepat dan bertahap pada unit.

Mengapa Mengintegrasikan Pengujian Unit ke dalam CI/CD?

Pengujian unit memberikan nilai paling besar ketika dihubungkan langsung ke integrasi berkelanjutan dan saluran pengiriman berkelanjutan (CI/CD). Alih-alih menjadi renungan, mereka menjadi gerbang berkualitas yang secara otomatis memvalidasi setiap perubahan sebelum dikirim.

Berikut adalah alasan untuk mengintegrasikan pengujian unit ke dalam jalur CI/CD:

  • Umpan balik langsung – Pengembang mengetahui dalam hitungan menit jika perubahan yang mereka buat merusak sesuatu.
  • Shift-kualitas kiri – Bug ditemukan pada waktu komit, bukan setelah rilis.
  • Keyakinan dalam penempatan – Pemeriksaan otomatis memastikan bahwa “build hijau” aman untuk diluncurkan.
  • Kolaborasi yang dapat diskalakan – Tim dengan ukuran apa pun dapat menggabungkan kode tanpa saling mengganggu.

Mitos Pengujian Unit

Berikut adalah beberapa mitos umum tentang Pengujian Unit:

"Butuh waktu, dan saya selalu terlalu sibuk. Kode saya sangat solid! Saya tidak perlu uji unit."

Mitos pada dasarnya adalah asumsi yang salah. Asumsi ini mengarah pada lingkaran setan sebagai berikut –

Mitos Pengujian UNIT

Faktanya, pengujian unit meningkatkan kecepatan pengembangan.

Para programmer berpikir bahwa Pengujian Integrasi akan mendeteksi semua kesalahan dan tidak menjalankan pengujian unit. Setelah unit terintegrasi, kesalahan-kesalahan sederhana yang sebenarnya dapat dengan mudah ditemukan dan diperbaiki dalam pengujian unit membutuhkan waktu yang sangat lama untuk dilacak dan diperbaiki.

Keuntungan Pengujian Unit

  • Pengembang yang ingin mempelajari fungsionalitas apa yang disediakan oleh suatu unit dan cara menggunakannya dapat melihat pengujian unit untuk mendapatkan pemahaman dasar tentang API unit.
  • Pengujian unit memungkinkan programmer untuk melakukan refaktor kode di kemudian hari dan memastikan modul masih berfungsi dengan benar (misalnya, Pengujian regresi). Prosedurnya adalah dengan menulis kasus uji untuk semua fungsi dan metode sehingga setiap kali perubahan menyebabkan kesalahan, maka dapat dengan cepat diidentifikasi dan diperbaiki.
  • Karena sifat modular dari pengujian unit, kami dapat menguji bagian proyek tanpa menunggu bagian lain selesai.

Kekurangan Pengujian Unit

  • Pengujian unit tidak dapat diharapkan untuk mendeteksi setiap kesalahan dalam suatu program. Tidak mungkin untuk mengevaluasi semua jalur eksekusi, bahkan dalam program yang paling sederhana sekalipun.
  • Pengujian unit pada dasarnya berfokus pada satu unit kode. Oleh karena itu, pengujian ini tidak dapat mendeteksi kesalahan integrasi atau kesalahan sistem yang luas.

Disarankan agar pengujian unit digunakan bersama dengan aktivitas pengujian lainnya.

Praktik Terbaik Pengujian Unit

  • Kasus Uji Unit harus independen. Jika terjadi peningkatan atau perubahan persyaratan, kasus uji unit tidak boleh terpengaruh.
  • Uji hanya satu kode dalam satu waktu.
  • Ikuti konvensi penamaan yang jelas dan konsisten untuk pengujian unit Anda
  • Jika terjadi perubahan kode di modul mana pun, pastikan ada unit yang sesuai Uji Kasus untuk modul, dan modul lulus pengujian sebelum mengubah implementasinya
  • Bug yang teridentifikasi selama pengujian unit harus diperbaiki sebelum melanjutkan ke tahap berikutnya dalam SDLC
  • Gunakan pendekatan “tes sebagai kode Anda”. Semakin banyak kode yang Anda tulis tanpa pengujian, semakin banyak jalur yang harus Anda periksa kesalahannya.

Praktik Terbaik Pengujian Unit

Pertanyaan Umum (FAQ)

Pengujian unit mencakup varian manual, otomatis, kotak putih, kotak hitam, regresi, dan integrasi. Pendekatannya bergantung pada apakah Anda memvalidasi jalur logika individual, memverifikasi perilaku terhadap persyaratan, atau memastikan tidak ada bug yang muncul kembali setelah perubahan kode.

Langkah-langkahnya meliputi analisis kebutuhan, penulisan kasus uji, penyiapan data uji, pelaksanaan uji, perbandingan hasil aktual dengan hasil yang diharapkan, perbaikan cacat, dan pengujian ulang. Terakhir, pengujian dipelihara dan diotomatisasi untuk memastikan cakupan yang berkelanjutan dan umpan balik yang lebih cepat.

Pengujian unit memvalidasi potongan kode kecil secara terpisah, biasanya otomatis dan dipimpin oleh pengembang. Pengujian QA memiliki cakupan yang lebih luas—memastikan seluruh aplikasi berfungsi dengan benar, memenuhi persyaratan pengguna, dan terintegrasi dengan lancar—seringkali melalui pengujian fungsional, sistem, dan penerimaan.

Keterampilan utama yang dibutuhkan untuk pengujian unit adalah pengetahuan pemrograman yang kuat, keahlian debugging, keakraban dengan kerangka kerja pengujian (JUnit, NUnit, PyTest), perhatian terhadap detail, pemikiran logis, dan pemahaman prinsip-prinsip desain perangkat lunak. Pengalaman otomatisasi dan integrasi CI/CD membuat pengujian lebih cepat dan lebih andal.

Ringkasan

Pengujian unit adalah fondasi kualitas perangkat lunak modern. Dengan memverifikasi kode pada tingkat terkecil, pengujian unit mencegah penyebaran cacat, mempercepat pengembangan, dan memberi tim keyakinan untuk menyelesaikan pengembangan lebih cepat.

Bila dikombinasikan dengan praktik yang terbukti — seperti Pola AAA, penuh pertimbangan teknik, tujuan cakupan, dan Integrasi CI / CD — pengujian unit berkembang dari pemeriksaan sederhana menjadi jaring pengaman hidup yang tumbuh bersama basis kode Anda.

Namun, keseimbangan adalah kuncinya. Hindari pengujian kode yang terlalu sepele, terlalu banyak mengejek dependensi, atau mengejar metrik kesombongan seperti cakupan 100%. Sebaliknya, fokuskan upaya pada logika bisnis penting, komponen yang dapat digunakan kembali, dan area berisiko tinggi, di mana pengujian memberikan hasil terbesar.

Singkatnya, pengujian unit bukan hanya tentang menulis pengujian — ini tentang membangun budaya kepercayaan, pemeliharaan, dan perbaikan berkelanjutanTim yang berinvestasi di dalamnya menuai manfaat jangka panjang: lebih sedikit bug, kode lebih bersih, dan rilis lebih lancar.