Pengujian unit: Perbedaan antara revisi
Konten dihapus Konten ditambahkan
Wagino Bot (bicara | kontrib) |
Fitur saranan suntingan: 3 pranala ditambahkan. Tag: VisualEditor Suntingan perangkat seluler Suntingan peramban seluler Tugas pengguna baru Disarankan: tambahkan pranala |
||
Baris 27:
=== Desain ===
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.
Baris 128:
Hal penting pula untuk menerapkan proses yang berkelanjutan untuk memastikan bahwa kegagalan kasus uji ditinjau setiap hari dan segera diatasi.<ref>{{Cite web|url=http://www.ddj.com/development-tools/206105233|title=Change Code Without Fear: Utilize a regression safety net|last=daVeiga|first=Nada|authorlink=Nada daVeiga|date=2008-02-06|access-date=2008-02-08}}</ref> Jika proses tersebut tidak dilaksanakan dan tidak tertanam ke dalam alur kerja tim, aplikasi akan berkembang liar, tidak lagi selaras dengan kumpulan pengujian unit, meningkatkan positif palsu dan mengurangi keefektifan kumpulan pengujian.
Pengujian unit perangkat lunak [[Sistem terbenam|sistem benam]] (embedded system) menghadirkan tantangan unik: karena perangkat lunak tersebut dikembangkan pada landasan yang berbeda dari landasan yang nantinya akan menjalankannya, Anda tidak dapat dengan mudah menjalankan program pengujian pada lingkungan pelaksanaan (deployment) sebenarnya, seperti yang mungkin dilakukan dengan program desktop.<ref>{{Cite web|url=http://electronicdesign.com/article/embedded/Making-Unit-Testing-Practical-for-Embedded-Development|title=Making Unit Testing Practical for Embedded Development|last=Kucharski|first=Marek|authorlink=Marek Kucharski|date=2011-11-23|access-date=2012-05-08}}</ref>
== Aplikasi ==
Baris 153:
=== Kerangka kerja unit pengujian ===
Kerangka kerja unit pengujian biasanya adalah produk pihak ketiga yang tidak didistribusikan sebagai bagian dari rangkaian pengkompilasi ([[Kompilator|compiler]] suite). Kerangka kerja ini membantu menyederhanakan proses pengujian unit, dan telah dikembangkan untuk berbagai macam bahasa pemrograman. Contoh kerangka kerja pengujian mencakup solusi sumber terbuka seperti berbagai kerangka kerja yang dikenal secara kolektif sebagai xUnit, dan solusi komersial seperti Typemock Isolator.NET/Isolator++, TBrun, JustMock, Parasoft Development Testing (Jtest, Parasoft C/C++tes, dotTEST), Testwell CTA++ dan VectorCAST/C++.
Biasanya kita dapat melakukan pengujian unit tanpa dukungan dari kerangka kerja tertentu dengan menulis kode klien yang menjalankan unit yang diuji test dan menggunakan penegasan, [[Penanganan pengecualian|penanganan eksepsi]], atau mekanisme pengendali aliran lainnya untuk memberi tanda kegagalan. Pengujian unit tanpa kerangka kerja adalah berharga karena ada halangan adopsi pengujian unit; memiliki sedikit pengujian unit tidak lebih baik daripada tidak ada sama sekali, padahal sekali kerangka kerja sudah diterapkan, menambahkan pengujian unit menjadi relatif mudah.<ref>{{Cite web|url=http://www.bullseye.com/coverage.html|title=Intermediate Coverage Goals|last=Bullseye Testing Technology|date=2006–2008|access-date=24 March 2009}}</ref> Pada beberapa kerangka kerja yang banyak fitur pengujian unit yang tidak ada atau harus ditulis secara manual.
| |||