1. UNIT TESTING
Dalam pemrograman komputer, unit testing adalah metode dimana unit individu dari kode sumber, menetapkan satu atau lebih modul program komputer bersama-sama dengan data kontrol terkait, prosedur penggunaan, dan prosedur operasi diuji untuk menentukan apakah mereka layak digunakan. Secara intuitif, kita dapat melihat unit sebagai bagian diuji terkecil dari sebuah aplikasi. Dalam pemrograman prosedural unit bisa menjadi modul seluruh tetapi lebih umum fungsi individu atau prosedur. Dalam pemrograman berorientasi obyek unit sering merupakan seluruh antarmuka, seperti kelas, tetapi bisa menjadi metode individu. Unit test yang dibuat oleh programmer atau kadang-kadang oleh penguji kotak putih selama proses pembangunan.
Idealnya, setiap kasus uji independen dari yang lain: pengganti seperti bertopik metode, objek tiruan, palsu dan memanfaatkan tes dapat digunakan untuk membantu pengujian modul secara terpisah. Unit test biasanya ditulis dan dijalankan oleh pengembang perangkat lunak untuk memastikan bahwa kode memenuhi desain dan berperilaku sebagaimana dimaksud. Pelaksanaannya dapat bervariasi dari yang sangat manual (pensil dan kertas). Untuk yang diformalkan sebagai bagian dari otomatisasi membangun.
2. MANFAAT UNIT TESTING
Tujuan dari unit testing adalah untuk mengisolasi setiap bagian dari program dan menunjukkan bahwa bagian-bagian individu sudah benar. Sebuah tes unit menyediakan kontrak, ketat ditulis bahwa potongan kode harus memenuhi. Akibatnya afford dapat dibagi menjadi beberapa manfaat atau keuntungan, diantaranya :
2.1 Pencarian Masalah Awal
Unit test menemukan masalah di awal siklus pengembangan. Pada tes-driven (TDD), yang sering digunakan dalam kedua Extreme Programming dan Scrum, unit test dibuat sebelum kode itu sendiri ditulis. Jika tes lulus, kode yang dianggap lengkap. Unit test yang sama dijalankan terhadap fungsi yang sering sebagai basis kode yang lebih besar dikembangkan baik sebagai kode diubah atau melalui proses otomatis dengan membangun. Jika unit test gagal, dianggap bug baik dalam kode berubah atau tes sendiri. Unit test kemudian memungkinkan letak kesalahan atau kegagalan untuk dapat dengan mudah dilacak. Karena unit test mengingatkan tim pengembangan dari masalah sebelum menyerahkan kode ke penguji atau klien, masih di awal proses pembangunan.
2.2 Memfasilitasi Perubahan
Unit pengujian memungkinkan programmer untuk kode refactor di kemudian hari, dan pastikan modul masih bekerja dengan benar (misalnya, dalam pengujian regresi). Prosedur ini menulis kasus uji untuk semua fungsi dan metode sehingga setiap kali perubahan menyebabkan kesalahan, dapat dengan cepat diidentifikasi dan diperbaiki. Tes unit tersedia memudahkan para programmer untuk memeriksa apakah sepotong kode masih bekerja dengan benar. Dalam lingkungan pengujian unit terus menerus, melalui praktek yang melekat pemeliharaan berkelanjutan, unit test akan terus secara akurat mencerminkan tujuan penggunaan executable dan kode dalam menghadapi perubahan. Tergantung pada praktek-praktek pembangunan yang ditetapkan dan cakupan unit uji, up-to-the-detik akurasi dapat dipertahankan.
2.3 Menyederhanakan Integrasi
Unit pengujian dapat mengurangi ketidakpastian dalam unit sendiri dan dapat digunakan dalam pendekatan gaya bottom-up pengujian. Dengan menguji bagian dari sebuah program pertama dan kemudian menguji jumlah bagian-bagiannya, pengujian integrasi menjadi lebih mudah. Hirarki yang rumit unit test tidak pengujian integrasi sama. Integrasi dengan unit perangkat harus dimasukkan dalam tes integrasi, tapi tidak dalam unit test Integrasi pengujian biasanya masih sangat bergantung pada manusia pengujian manual;. Pengujian tingkat tinggi atau global-scope bisa sulit untuk mengotomatisasi, sehingga pengujian manual sering muncul lebih cepat dan lebih murah.
2.4 Dokumentasi
Unit pengujian menyediakan semacam dokumentasi hidup dari sistem. Pengembang yang ingin belajar apa fungsi disediakan oleh unit dan bagaimana menggunakannya dapat melihat unit test untuk mendapatkan pemahaman dasar API unit. Satuan kasus uji mewujudkan karakteristik yang sangat penting untuk keberhasilan unit. Karakteristik ini dapat menunjukkan penggunaan yang tepat / tidak tepat unit serta perilaku negatif yang akan terjebak oleh unit. Sebuah kasus uji unit, dalam dan dari dirinya sendiri, mendokumentasikan karakteristik kritis, meskipun lingkungan pengembangan perangkat lunak yang tidak hanya mengandalkan kode untuk mendokumentasikan produk dalam pembangunan. Sebaliknya, dokumentasi naratif biasa lebih rentan terhadap melayang dari pelaksanaan program dan dengan demikian akan menjadi usang (misalnya, perubahan desain, terobosan fitur, praktek santai dalam menjaga dokumen up-to-date).
2.5 Disain
Ketika perangkat lunak dikembangkan dengan menggunakan pendekatan uji-driven, tes unit bisa menggantikan desain formal. Setiap unit test dapat dilihat sebagai elemen desain menentukan kelas, metode, dan perilaku yang dapat diamati. Contoh Jawa berikut akan membantu menggambarkan hal ini. Berikut ini adalah kelas tes yang menentukan sejumlah elemen pelaksanaan. Pertama, bahwa harus ada sebuah antarmuka yang disebut Adder, dan kelas yang mengimplementasikan dengan konstruktor nol-argumen disebut AdderImpl. Ini melanjutkan dengan menegaskan bahwa antarmuka Adder harus memiliki metode yang disebut menambahkan, dengan dua parameter bilangan bulat, yang mengembalikan bilangan bulat lain. Hal ini juga menentukan perilaku dari metode ini untuk berbagai nilai-nilai kecil.
public class TestAdder {
public void testSum() {
Adder adder = new AdderImpl();
// can it add positive numbers?
assert(adder.add(1, 1) == 2);
assert(adder.add(1, 2) == 3);
assert(adder.add(2, 2) == 4);
// is zero neutral?
assert(adder.add(0, 0) == 0);
// can it add negative numbers?
assert(adder.add(-1, -2) == -3);
// can it add a positive and a negative?
assert(adder.add(-1, 1) == 0);
// how about larger numbers?
assert(adder.add(1234, 988) == 2222);
}
}
Dalam hal ini tes unit, yang telah tertulis pertama, bertindak sebagai dokumen desain menentukan bentuk dan perilaku solusi yang diinginkan, tetapi tidak rincian pelaksanaan, yang tersisa untuk programmer. Setelah praktek "melakukan hal sederhana yang mungkin bisa bekerja", solusi yang paling mudah yang akan membuat lulus tes ditampilkan di bawah.
interface Adder {
int add(int a, int b);
}
class AdderImpl implements Adder {
int add(int a, int b) {
return a + b;
}
}
Tidak seperti diagram berbasis metode desain, menggunakan unit-test sebagai sebuah desain memiliki satu keuntungan yang signifikan. Dokumen desain (unit-tes itu sendiri) dapat digunakan untuk memverifikasi bahwa pelaksanaannya menganut desain. Dengan metode desain unit-test, tes tidak akan lulus jika pengembang tidak mengimplementasikan solusi sesuai dengan desain.
Memang benar bahwa unit testing tidak memiliki beberapa aksesibilitas diagram, tetapi UML diagram sekarang mudah dihasilkan untuk sebagian besar bahasa modern dengan alat gratis (biasanya tersedia sebagai ekstensi untuk IDE). Alat gratis, seperti yang didasarkan pada kerangka xUnit, outsourcing ke sistem rendering grafis dari pandangan untuk konsumsi manusia.
3. Pemisahan Interface dari Implementasi
Karena beberapa kelas dapat memiliki referensi ke kelas lain, pengujian kelas sering dapat meluas ke pengujian kelas lain. Sebuah contoh umum ini adalah kelas yang tergantung pada database: untuk menguji kelas, tester sering menulis kode yang berinteraksi dengan database. Ini suatu kesalahan, karena tes unit harus biasanya tidak pergi ke luar dari batas kelas sendiri, dan terutama tidak harus menyeberangi proses seperti / jaringan batas karena ini dapat memperkenalkan masalah kinerja tidak dapat diterima ke unit uji-suite. Melintasi batas-batas unit tersebut ternyata tes unit menjadi tes integrasi, dan ketika uji kasus gagal, membuatnya kurang jelas komponen yang menyebabkan kegagalan. Lihat juga Fakes, mengolok-olok dan tes integrasi
Sebaliknya, pengembang perangkat lunak harus membuat sebuah antarmuka abstrak sekitar query database, dan kemudian mengimplementasikan interface dengan objek yang pura-pura terhadap mereka. Dengan abstrak ini lampiran yang diperlukan dari kode (sementara mengurangi kopling efektif bersih), unit independen dapat lebih benar-benar teruji dari Mei sebelumnya telah tercapai. Hal ini menghasilkan unit kualitas lebih tinggi yang juga lebih maintainable.
4. Parameterized Pengujian Unit (PUT)
Unit Pengujian parameter (PUTS) adalah tes yang mengambil parameter. Tidak seperti tes unit tradisional, yang biasanya metode tertutup, menempatkan mengambil set parameter. PUTS telah didukung oleh JUnit 4 dan berbagai. NET kerangka uji. Parameter Cocok untuk unit test mungkin diberikan secara manual atau dalam beberapa kasus yang secara otomatis dihasilkan oleh kerangka pengujian. Berbagai alat pengujian industri juga ada untuk menghasilkan masukan tes untuk PUTS.
5. Unit Pengujian Keterbatasan
Pengujian tidak dapat diharapkan untuk menangkap setiap kesalahan dalam program ini: tidak mungkin untuk mengevaluasi setiap jalur eksekusi dalam semua kecuali program yang paling sepele. Hal yang sama berlaku untuk unit testing. Selain itu, unit testing secara definisi hanya menguji fungsionalitas dari unit itu sendiri. Oleh karena itu, tidak akan menangkap kesalahan integrasi atau lebih luas sistem tingkat kesalahan (seperti fungsi dilakukan di beberapa unit, atau non-fungsional daerah uji seperti kinerja). Unit pengujian harus dilakukan dalam hubungannya dengan kegiatan pengujian perangkat lunak lain. Seperti semua bentuk pengujian perangkat lunak, tes unit hanya bisa menunjukkan adanya kesalahan, mereka tidak dapat menunjukkan tidak adanya kesalahan.
Software pengujian adalah masalah kombinatorial. Misalnya, setiap pernyataan keputusan boolean memerlukan setidaknya dua tes: satu dengan hasil dari "benar" dan satu dengan hasil dari "false". Akibatnya, untuk setiap baris kode yang ditulis, programmer sering perlu 3 sampai 5 baris kode tes. Hal ini jelas membutuhkan waktu dan investasi mungkin tidak layak usaha.. Ada juga banyak masalah yang tidak dapat dengan mudah diuji sama sekali - misalnya mereka yang nondeterministic atau melibatkan beberapa thread. Selain itu, menulis kode untuk tes unit adalah sebagai mungkin setidaknya sama kereta sebagai kode itu adalah pengujian. Fred Brooks dalam The Man-Bulan kutipan Mythical: tidak pernah mengambil dua kronometer ke laut. Selalu mengambil satu atau tiga. Artinya, jika dua kronometer bertentangan, bagaimana Anda tahu mana yang benar?
Untuk mendapatkan manfaat dimaksudkan dari unit testing, disiplin ketat diperlukan selama proses pengembangan perangkat lunak. Penting untuk menyimpan catatan-hati tidak hanya dari tes yang telah dilakukan, tetapi juga dari semua perubahan yang telah dibuat pada kode ini atau unit lain dalam perangkat lunak. Penggunaan sistem kontrol versi sangat penting. Jika versi yang lebih baru unit gagal tes tertentu yang sebelumnya berlalu, perangkat lunak versi-kontrol dapat memberikan daftar perubahan kode sumber (jika ada) yang telah diterapkan pada unit sejak saat itu.
Hal ini juga penting untuk menerapkan proses yang berkelanjutan untuk memastikan kegagalan uji kasus yang terakhir setiap hari dan segera diatasi. Jika proses tersebut tidak diterapkan dan mendarah daging ke dalam alur kerja tim, aplikasi akan berkembang tidak sinkron dengan unit test suite, meningkatkan positif palsu dan mengurangi efektivitas suite uji.
Unit pengujian perangkat lunak sistem tertanam menghadirkan tantangan yang unik: Karena perangkat lunak sedang dikembangkan pada platform yang berbeda dari yang pada akhirnya akan berjalan pada, Anda tidak dapat dengan mudah menjalankan program tes di lingkungan penyebaran yang nyata, seperti yang mungkin dengan program-program desktop.
6. Aplikasi
6.1 Ekstrim Pemrograman
Unit pengujian adalah dasar dari pemrograman ekstrim, yang bergantung pada kerangka unit testing otomatis. Kerangka unit otomatis pengujian dapat berupa pihak ketiga, misalnya, xUnit, atau dibuat dalam kelompok pengembangan.
Pemrograman ekstrim menggunakan penciptaan unit test untuk test-driven. Pengembang menulis tes unit yang mengekspos baik persyaratan perangkat lunak atau cacat. Tes ini akan gagal karena baik persyaratan belum diimplementasikan, atau karena sengaja mengekspos cacat dalam kode yang ada. Kemudian, pengembang menulis kode sederhana untuk membuat tes, bersama dengan tes lainnya, lulus.
Kode yang paling dalam suatu sistem satuan diuji, tetapi belum tentu semua jalan melalui kode. Ekstrim pemrograman mandat "uji segala sesuatu yang mungkin dapat mematahkan" strategi, atas "menguji setiap jalur eksekusi" tradisional metode. Hal ini menyebabkan pengembang untuk mengembangkan tes yang lebih sedikit daripada metode klasik, tapi ini bukan masalah, lebih merupakan penyajian kembali fakta, sebagai metode klasik jarang pernah diikuti metodis cukup untuk semua path eksekusi telah diuji secara menyeluruh. [Rujukan?] pemrograman ekstrim hanya mengakui bahwa tes ini jarang lengkap (karena sering terlalu mahal dan memakan waktu layak secara ekonomi) dan menyediakan panduan tentang cara efektif memfokuskan sumber daya terbatas.
Krusial, kode tes dianggap sebagai proyek artefak kelas satu dalam hal itu dipertahankan pada kualitas yang sama seperti kode implementasi, dengan semua duplikasi dihapus. Pengembang merilis kode unit pengujian untuk repositori kode dalam hubungannya dengan kode itu tes. Unit testing menyeluruh pemrograman ekstrim ini memungkinkan manfaat yang disebutkan di atas, seperti pengembangan kode sederhana dan lebih percaya diri dan refactoring, integrasi kode disederhanakan, dokumentasi yang akurat, dan desain modular lebih. Tes ini satuan juga terus berjalan sebagai bentuk uji regresi.
Unit pengujian juga penting untuk konsep Desain Muncul. Sebagai Desain Muncul sangat tergantung pada Refactoring, unit test adalah komponen integral [6].
6.2 Teknik
Unit pengujian umumnya otomatis, tetapi masih mungkin dilakukan secara manual. IEEE tidak mendukung salah satu dari yang lain. [7] Pendekatan manual untuk unit testing dapat mempekerjakan dokumen langkah-demi-langkah instruksional. Namun demikian, tujuan dalam unit testing adalah untuk mengisolasi unit dan memvalidasi kebenaran nya. Otomasi adalah efisien untuk mencapai hal ini, dan memungkinkan banyak manfaat yang tercantum dalam artikel ini. Sebaliknya, jika tidak direncanakan dengan hati-hati, unit panduan ujian ceroboh dapat mengeksekusi sebagai kasus uji integrasi yang melibatkan banyak komponen perangkat lunak, dan dengan demikian menghalangi pencapaian kebanyakan jika tidak semua tujuan yang ditetapkan untuk unit testing.
Untuk sepenuhnya menyadari efek isolasi sementara dengan menggunakan pendekatan otomatis, unit atau badan yang diuji kode dijalankan dalam kerangka luar lingkungan alamnya. Dengan kata lain, dieksekusi di luar produk atau konteks menyerukan yang awalnya dibuat. Pengujian sedemikian secara terisolasi mengungkapkan dependensi yang tidak perlu antara kode yang diuji dan unit lain atau ruang data dalam produk. Dependensi ini kemudian dapat dihilangkan.
Menggunakan framework otomatisasi, kode pengembang kriteria ke dalam tes untuk memverifikasi kebenaran unit. Selama pelaksanaan uji kasus, kerangka log tes yang gagal kriteria apapun. Kerangka Banyak juga akan secara otomatis bendera uji kasus gagal dan melaporkannya dalam ringkasan. Tergantung pada tingkat keparahan kegagalan, kerangka kerja ini dapat menghentikan pengujian berikutnya.
Akibatnya, unit testing secara tradisional motivator bagi programmer untuk membuat tubuh kode dipisahkan dan kohesif. Praktek ini mendorong kebiasaan sehat dalam pengembangan perangkat lunak. Desain pola, unit testing, dan refactoring sering bekerja bersama sehingga solusi terbaik mungkin muncul.
6.3 AUnit Pengujian Kerangka
Satuan kerangka pengujian yang paling sering Produk pihak ketiga yang tidak didistribusikan sebagai bagian dari suite compiler. Mereka membantu menyederhanakan proses pengujian unit, yang telah dikembangkan untuk berbagai macam bahasa. Contoh kerangka pengujian meliputi solusi open source seperti kode berbasis kerangka kerja berbagai pengujian dikenal secara kolektif sebagai xUnit, dan solusi proprietary / komersial seperti TBrun, JustMock, Isolator.NET, Isolator + +, Testwell CTA + + dan VectorCAST / C + +.
Hal ini umumnya mungkin untuk melakukan unit testing tanpa dukungan kerangka tertentu dengan menulis kode klien yang melatih unit yang diuji dan menggunakan pernyataan, pengecualian penanganan, atau mekanisme kontrol lainnya mengalir ke sinyal kegagalan. Unit pengujian tanpa kerangka kerja berharga dalam bahwa ada hambatan masuk untuk adopsi pengujian unit; memiliki unit test sedikit hampir tidak lebih baik daripada memiliki tidak sama sekali, sedangkan sekali kerangka di tempat, menambahkan unit test menjadi relatif mudah. [8] Dalam beberapa framework fitur canggih satuan banyak tes yang hilang atau harus tangan-kode.
Bahasa tingkat unit pengujian dukungan
Beberapa bahasa pemrograman langsung mendukung unit testing. Tata bahasa mereka memungkinkan deklarasi langsung dari unit test tanpa mengimpor perpustakaan (baik pihak ketiga atau standar). Selain itu, kondisi boolean unit test dapat dinyatakan dalam sintaks yang sama sebagai ekspresi boolean digunakan dalam non-unit kode tes, seperti apa yang digunakan untuk laporan jika dan sementara.
Bahasa yang langsung mendukung unit testing meliputi:
C #
Corba
D
Jawa
Obix
Sumber : http://en.wikipedia.org/wiki/Unit_testing
