Unit Test 101

Unit test, mendengar namanya sepertinya cukup familiar terutama jika anda seorang software engineer. Betul, satu metode yang sudah tidak rahasia lagi paling malas dilakukan oleh kebanyakan engineer, salah satu alasannya adalah karena mereka pikir bahwa menulis unit test hanya akan membuang-buang waktu. Selama metode manual test yang mereka lakukan berhasil, mengapa kita menghabiskan waktu lagi untuk menulis kode hanya untuk melakukan tugas yang cukup dengan manual testing. Artikel kali ini akan membahas secara singkat dasar pengetahuan tentang unit test, beberapa fakta dan miskonsepsi tentang unit test. Mari kita bahas definisi unit test untuk memulai.

Unit Test

https://semaphoreci.com/blog/testing-pyramid

Unit testing adalah metode pengujian yang dibangun di atas ide untuk menguji program dengan memecah fungsionalitas dari program yang kita bangun menjadi fungsionalitas yang lebih kecil dan bisa diuji sebagai unit individual. Kata kunci yang perlu diperhatikan di sini adalah unit individual. Ketika kita melakukan unit test, yang harus diperhatikan adalah kita benar-benar melakukan satu pengujian hanya untuk satu unit.

Secara sederhana, pengertian istilah unit sendiri dalam unit test yaitu adalah suatu komponen yang dipecah menjadi independen terhadap komponen lainnya. Dalam paradigma Object-Oriented unit bisa diartikan sebagai class, sedangkan pada paradigma Functional Programming unit diartikan sebagai function. Tetapi perlu diperhatikan bahwa pengertian unit ini masih bisa diinterpretasikan terhadap sesuatu yang berbeda, tergantung situasinya, jadi jangan selalu tergantung pada definisi yang saya paparkan.

Manfaat Unit Test

Salah satu miskonsepsi atau mitos yang sering didengar adalah penulisan unit test memakan waktu yang cukup lama, bahkan bisa sampai dua kali waktu development unit. Faktanya, menurut penelitian dari Microsoft, durasi waktu yang dihabiskan untuk menulis unit test hanya berkisar sekitar 20% dari keseluruhan development. 20% waktu tambahan ini bisa berdampak pada berkurangnya defect yang muncul ketika pengujian oleh QA sebesar 20,9%, selain itu juga mengurangi waktu yang dihabiskan kedepannya untuk fixing bug yang muncul di masa depan.

https://collaboration.csc.ncsu.edu/laurie/Papers/Unit_testing_cameraReady.pdf

Dengan menulis unit test, menurut penelitian Microsoft kita sebagai engineer juga akan merasa lebih percaya diri untuk deliver code kita kepada QA dengan skor 80–90%. Hal ini akan berdampak pada kecepatan kita dalam deliver code. Kualitas yang dihasilkan juga akan meningkat secara pesat dengan menerapkan unit test dan dokumentasi baik dan benar.

Unit Test Best Practice

Jelas dan Detail

Unit test harus ditulis dengan sangat jelas dan detail, dengan ini kita secara otomatis bisa membuat dokumentasi tentang behavior dari unit yang sedang kita uji. Untuk memulai menulis unit test yang jelas dan detail bisa dimulai dari nama function tiap test. Template yang biasa saya gunakan adalah behaviorUnit_kondisiDanFaktor_ekspektasiHasil. Selain itu, usahakan untuk selalu menulis kode pengujian dengan rapi, bisa dimulai dengan nama variabel yang singkat namun deskriptif. Contoh bagaimana unit test yang selalu saya tekankan.

Full Coverage

Ketika menulis unit test, usahakan untuk selalu mengcover semua kemungkinan yang akan terjadi pada business logic. Semua conditional yang ada pada unit harus diusahakan masuk pada unit test, hal ini bisa dilakukan dengan membuat beberapa unit test untuk masing-masing kasus yang masuk dalam cabang conditional. Beberapa framework testing memiliki fitur untuk mengukur coverage dari unit test yang kita buat, pastikan kita mengutilisasi fitur itu dengan maksimal.

Unit Terisolasi

https://martinfowler.com/bliki/images/unitTest/isolate.png

Hal ini sebenarnya masih terjadi perdebatan, sesuai gambar di atas, ada dua jenis metode yang bisa dilakukan

1. Sociable test, yaitu metode untuk tetap memanggil dependency dari sebuah unit yang akan diuji secara real. Belakangan ini, metode ini sudah jarang digunakan karena sifatnya yang non-deterministik. Sebagai engineer, kita bisa saja ada dalam situasi di mana kita tidak tahu kapan dependency yang dipanggil secara real akan gagal atau berhasil. Contohnya ketika behavior sebuah unit ingin mengambil data dengan cara outbound call ke service lain, kita tidak tahu kapan akan terjadi network failure dan sebagainya. Hal ini akan menyulitkan kita untuk menguji unit secara full coverage.
2. Solitary Test, yaitu metode untuk mengisolasi unit yang kita uji dengan dependency yang akan dipanggil. Metode isolasi ini bisa dilakukan dengan cara populer yang dinamakan “mocking”. Dengan menggunakan metode ini, kita bisa menentukan hasil yang akan dikembalikan oleh dependency lain, sehingga kita bisa mengcover semua conditional pada business logic unit secara deterministik. Contoh bisa dilihat pada gambar sebelumnya, di pengujian itu saya mock hasil dari customerDao. Saya bisa atur dan tentukan customerDao untuk mengembalikan objek Customer ataupun malah mengembalikan error not found.

Saya sendiri beranggapan bahwa untuk melakukan unit test, metode terbaik adalah dengan menggunakan Solitary Test. Dengan menggunakan metode ini, istilah dari unit test sendiri sejajar. Apabila kita menggunakan Sociable Test, yang kita lakukan justru keluar dari ranah unit test dan malah masuk ke dalam Integration Test karena menghadirkan panggilan secara real kepada beberapa dependency lain. Sifat dari sociable yang non-deterministik juga tidak bisa diprediksi, bayangkan ketika kita ingin deliver program kita malah mendapati unit test kita kadang error dan kadang juga berhasil, hal ini akan menghambat delivery time menjadi lebih lama.