Pengujian unit
Dalam pemrograman komputer, pengujian unit adalah sebuah metode pengujian perangkat lunak. Pada metode ini unit individu dari kode sumber, kumpulan dari satu atau lebih modul program komputer bersama-sama dengan kontrol data terkait, prosedur penggunaan, dan prosedur operasional, diuji untuk menentukan apakah mereka layak dipakai..
Secara intuitif, kita dapat melihat sebuah unit sebagai bagian terkecil yang dapat diuji dari sebuah aplikasi. Dalam pemrograman prosedural, unit bisa merupakan keseluruhan dari satu modul, tetapi biasanya yang menjadi unit adalah fungsi atau prosedur individual. Dalam pemrograman berorientasi objek, yang menjadi unit ini kerap kali keseluruhan antarmuka, seperti kelas, tetapi bisa jadi juga metode individual.
Pengujian unit adalah fragmen kode pendek yang dibuat oleh pemrogram atau kadang-kadang oleh penguji kotak putih selama proses pengembangan perangkat lunak. Ini membentuk dasar untuk komponen pengujian.
Idealnya, masing-masing kasus pengujian adalah independen satu sama lain. Pengganti seperti metode puntung, objek pura-pura, atau palsu, dan kekang uji (kerangka kerja uji terotomatisasi) dapat digunakan untuk membantu pengujian modul secara sendiri-sendiri. Pengujian unit biasanya ditulis dan dijalankan oleh pengembang perangkat lunak untuk memastikan bahwa kode program memenuhi desain dan berperilaku seperti yang dimaksudkan.
Tujuan dari pengujian unit adalah untuk mengisolasi setiap bagian dari program dan menunjukkan bahwa bagian-bagian individu program tersebut benar (sahih). Sebuah pengujian unit menyediakan kontrak tertulis yang ketat yang harus dipenuhi oleh sepotong kode program. Ada berbagai manfaat yang bisa didapat dari proses ini.
Pengujian unit menemukan masalah di awal dalam siklus pengembangan. Ini termasuk kekutu (Inggris: bug) dalam implementasi pemrogram dan kekurangan atau bagian-bagian yang hilang dari spesifikasi untuk unit tersebut. Proses penulisan kumpulan uji menyeluruh dari memaksa penulis untuk memikirkan masak-masak masukan, keluaran, dan kondisi kesalahan, dan dengan demikian lebih
tajam mendefinisikan perilaku unit yang diinginkan. Biaya untuk menemukan kekutu sebelum penulisan kode dimulai atau ketika kode ini pertama kali ditulis jauh lebih rendah daripada biaya mendeteksi, mengidentifikasi, dan memperbaiki bug sesudahnya; kekutu juga dapat menyebabkan masalah bagi pengguna akhir dari perangkat lunak. Beberapa berpendapat bahwa kode yang
tidak mungkin atau sulit dibikin pengujian unitnya adalah kode yang ditulis dengan buruk. Dengan demikian pengujian unit dapat memaksa pengembang untuk membuat struktur fungsi dan objek dalam cara yang lebih baik.
Dalam "pengembangan digerakkan pengujian" (test-driven development atau TDD), yang sering digunakan dalam pemrograman ekstrem dan scrum, pengujian unit diciptakan sebelum kode itu sendiri ditulis. Ketika lulus tes, kode itu dianggap selesai. Pengujian unit yang sama dijalankan terhadap fungsi itu berkali-kali seiring dengan pengembangan basis kode yang semakin besar, baik saat
kode itu berubah atau melalui proses yang diotomatisasi. Jika pengujian unit gagal, hal ini dianggap sebagai kekutu, baik di dalam kode yang sudah berubah itu atau dalam pengujian unit itu sendiri. Pengujian unit kemudian memungkinkan tempat kesalahan atau kegagalan tersebut dengan mudah dilacak. Karena pengujian unit memperingatkan tim pengembang akan masalah tersebut sebelum
kode program diserahkan ke untuk penguji atau klien, ini berarti masalah ditemukan masih dalam awal proses pengembangan perangkat lunak.
Pengujian unit memungkinkan pemrogram untuk merefaktor kode atau meng-upgrade pustaka sistem di kemudian hari, dan memastikan modul ini masih bekerja dengan benar (misalnya, dalam pengujian regresi). Prosedurnya adalah dengan menulis kasus uji untuk semua fungsi dan metode sehingga perubahan yang menyebabkan kesalahan, dapat dengan cepat diidentifikasi. Pengujian unit mendeteksi perubahan yang mungkin melanggar kontrak desain.
Pengujian unit dapat mengurangi ketidakpastian dalam unit itu sendiri dan dapat digunakan dalam pengujian bergaya pendekatan bottom-up. Dengan menguji bagian-bagian dari sebuah program terlebih dahulu, dan baru kemudian pengujian keseluruhan bagian secara terpadu, pengujian integrasi menjadi lebih mudah.
Pengujian unit menyediakan semacam dokumentasi hidup dari sistem. Pengembang yang ingin mempelajari apa saja fungsi yang disediakan sebuah unit, dan bagaimana menggunakannya, dapat melihat pengujian unit untuk mendapatkan pemahaman dasar tentang antarmuka pemrograman unit tersebut (API).
Kasus uji sebuah unit mengandung sifat-sifat yang sangat penting untuk keberhasilan unit tersebut. Sifat-sifat ini dapat menunjukkan penggunaan unit, baik yang tepat ataupun tidak layak, serta perilaku negatif yang akan dijebak oleh unit tersebut. Kasus uji sebuah unit mendokumentasikan semua karakteristik penting ini, meskipun banyak lingkungan pengembangan perangkat lunak yang tidak mengandalkan kode untuk mendokumentasikan produk yang sedang dikembangkan.
Ketika perangkat lunak dikembangkan dengan menggunakan pendekatan digerakkan pengujian, kombinasi dari menulis pengujian unit untuk menentukan antarmuka, ditambah dengan kegiatan refaktorisasi yang dilakukan setelah kelulusan uji, dapat mengambil alih desain formal. Masing-masing pengujian unit dapat dilihat sebagai elemen desain untuk menentukan kelas-kelas, metode, dan perilaku yang dapat diamati. Berikut contoh dalam bahasa pemrograman Java yang akan membantu menjelaskan hal ini.
Berikut ini adalah sekumpulan kasus uji yang menentukan sejumlah unsur-unsur implementasi. Pertama, harus ada sebuah antarmuka yang disebut "Adder," dan kelas yang mengimplementasi dengan konstruktor tanpa argumen yang disebut "AdderImpl". Kemudian kasus uji ini menegaskan bahwa antarmuka Adder harus memiliki sebuah metode yang disebut "add", dengan dua parameter integer (bilangan
bulat), yang menghasilkan integer pula. Kasus uji ini juga menentukan perilaku dari metode ini untuk kisaran nilai tertentu pada serangkaian metode uji.
Dalam hal ini pengujian unit, karena telah ditulis terlebih dahulu, bertindak sebagai dokumen desain yang menentukan bentuk dan perilaku dari solusi yang diinginkan, tapi tanpa perincian pelaksanaan. Perincian ini diserahkan kepada pemrogram. Mengikuti praktik "melakukan hal yang paling sederhana yang mungkin bisa bekerja", solusi termudah yang akan lulus pengujian ditunjukkan di bawah ini.
Tidak seperti metode desain berbasis diagram lainnya, menggunakan pengujian unit sebagai desain spesifikasi memiliki satu keuntungan penting. Dokumen desain (pengujian unit itu sendiri) dapat digunakan untuk memverifikasi bahwa implementasi mematuhi desain. Dengan metode desain pengujian unit, kode tidak akan pernah lulus uji jika pengembang tidak melaksanakan solusi sesuai dengan desain.
Memang benar bahwa pengujian unit tidak lebih mudah dipahami dibandingkan diagram, tetapi diagram UML saat ini dengan mudah dihasilkan buat sebagian besar bahasa-bahasa pemrograman modern menggunakan alat-alat gratis (biasanya tersedia sebagai ekstensi untuk IDEs). Alat-alat gratis ini, seperti yang berdasarkan kepada kerangka kerja xUnit kerangka, mengalihkan ke sistem lain tampilan grafis diagram untuk konsumsi manusia.
Karena beberapa kelas dapat memiliki referensi ke kelas-kelas lain, pengujian suatu kelas kerap kali berdampak ke pengujian kelas lain. Sebuah contoh umum dari hal ini adalah kelas yang tergantung pada sebuah basis data: untuk menguji kelas, penguji sering menulis kode yang berinteraksi dengan basis data. Ini adalah kesalahan, karena pengujian unit biasanya melanggar ke