Catatan Kecil Tentang Unit Testing
Pagi ini saya membaca beberapa artikel tentang testing. Tiba-tiba terbesit pikiran,
“Kayaknya udah pernah ngerangkum bab tentang unit testing deh”
Ternyata setelah mencari-cari, catatannya ada di salah satu trello card saya. Agar lebih mudah mencarinya, saya tulis artikel ini. Semoga banyak masukan dari para pembaca untuk memperbaikki pemahaman saya tentang unit test.
Sebenarnya saya dulu sempat menuliskan artikel tentang TDD yang bisa dibaca disini
Apa itu Unit Test?
Unit test adalah test untuk per unit kecil dari aplikasi kita.
- semisal kita mau testing komponen, itu artinya kita hanya mengetest satu komponen (satu unit)
- Custom Component yang ada di dalamnya, tidak ikut ditest.
- Umumnya yang di test adalah props yang dipassing benar atau tidak, terender atau tidak.
- Simulasi interaksi user (click, input, dll) apakah callbacknya sesuai atau tidak, jalan atau tidak.
Manfaat Unit Testing
Diambil dari situs https://vuejs.org/v2/cookbook/unit-testing-vue-components.html#Why-test
- Provide documentation on how the component should behave
- Save time over testing manually
- Reduce bugs in new features
- Improve design
- Facilitate refactoring
Tujuan Utama Testing
Tujuan utamannya Adalah untuk mengadakan kontrak dengan unit. Jadi kita juga bisa menuliskan behavior dari suatu unit (BDD — Behaviour Driven Development).
Semisal kita akan mengetest komponen Input Pertanyaan quiz dan jawabannya (pilihan gandanya). Maka kontraknya bisa ditulis sebagai berikut:
- Inputan Poin Quiz harus selalu ditampilkan
- Jika Quiz Essay, maka inputan jawaban dihilangkan
- Jika Quiz Essay, maka cukup satu jawaban saja yang di kirim ke Server
- Jika Quiz Choices, maka inputan jawaban harus muncul
- Jika Quiz Choices, jawabannya minimal berjumlah 4 jawaban
- Jika Quiz Choices, harus ada jawaban yang dianggap benar
- Jika merubah status Quiz, dari Choices ke Essay, jawaban yang telah ditulis sebelumnya tidak hilang / masih tersimpan
Kontrak di atas bisa menjadi gambaran atau desain komponen/unit yang akan kita buat nantinya. tentunya jika ada developer lain yang ingin mengerjakan atau mengedit komponen tsb. bisa melihat aturan pokok yang harus dipenuhi, yaitu kontrak BDD yang telah kita buat tadinya.
Secara garis besar Test digunakan untuk mendesain komponen, mendesain bagaimana behaviour dari suatu komponen.
Terkadang kita terlampau detil dalam menuliskan test hingga terdapat test-test yang sebenarnya tidak begitu kita butuhkan. Untuk menghindari hal tersebut, bisa menggunakan pendekatan BDD untuk penulisan garis besar dari spek suatu unit/komponen kita.
Syarat Unit Test
Diambil dari situs https://vuejs.org/v2/cookbook/unit-testing-vue-components.html#Why-test
- Harus cepat — tidak ada async function, ajax call, dll.
- Gunakan konsep container dan presentasional component
- Harus mudah dibaca
- Harus mudah dimengerti
- Hanya mengetest satu unit saja
Test Yang Tidak Layak
Ini adalah pemahaman saya setelah membaca artikel https://medium.freecodecamp.org/the-right-way-to-test-react-components-548a4736ab22. Saya menyimpulkan beberapa poin yang menurut saya patut dijadikan acuan.
*Untuk catatan, kali ini kita akan lebih fokus membahas tentang komponen, bukan unit secara general.
Test yang telah disediakan oleh library yang kita pakai
Semisal kita testing tipe data yang masuk ke props react component, padahal testing ini sudah dihandle oleh prop-types itu artinya kita tak perlu melakukannya lagi. Karena itu hanya sia-sia belaka.
Test yang mengharuskan kita untuk menulis ulang kode kita yang ada di main script
Semisal kita ingin testing inline style dari suatu komponen, alhasil kita harus melakukan testing secara rinci dan menyeluruh seperti memastikan warna background, font-size, dll. ini menyebabkan kita harus menulis ulang codingan inline style yang ada di komponen kita.
Tapi ada pengecualian. Semisal kita ingin mengecek dynamic styling yang akan berubah saat state / props dari komponen berubah, maka ini worth testing. Asal penulisannya tepat. Tidak sampai menulis ulang keseluruhan style. Melainkan Hanya bagian yang berubah saja.
Test mendetail tentang cara kerja internal dari komponen
Kita seharusnya hanya mengetest behaviour dari public method / public API yang disediakan oleh komponen. Semisal mengetest setiap props. entah itu props data maupun props function. jadi kita tak perlu testing seluruh method internal yang ada di dalam komponen satu-persatu. Hanya perlu testing API yang di ekspos ke luar/public
Tools
Berikut beberapa tools yang bisa digunakan untuk menunjang testing pada code kita. Khususnya web development.
React
Vue
- @vue/test-utils
- vue-jest
- https://tighten.co/blog/its-time-to-start-testing-your-vue-components-getting-started-with-jest
Kesimpulan
Dengan menuliskan Test, itu artinya kita mendesain atau mendefinisikan secara jelas spesifikasi dari komponen atau unit kita. Sehingga akan memudahkan rekan tim untuk melanjutkan ataupun memudahkan kita untuk memperbaikki bug yang terjadi.
Untuk memudahkan penulisan test, awali dengan menuliskan spek secara garis besar. Bisa berupa acceptance test ataupun behaviour test. Rinci boleh, asal test tersebut layak dan tidak sia-sia.
Penutup
Setiap detil isi konten dalam artikel ini tidak bermaksud untuk show off, menyinggung, menyindir, ataupun sejenisnya. Melainkan untuk catatan pribadi saya tentang testing itu sendiri.
Semoga para pembaca bisa mendapatkan benefit dari membaca artikel ini.
Sangat terbuka untuk kritik dan saran. Kalau saya salah, mohon dengan sangat untuk diingatkan. Semoga bermanfaat dan jangan lupa Clap and Share~
Let’s talk about some projects with me
Just Contact Me At:
- Email: bosnaufalemail@gmail.com
- Skype Id: bosnaufal254
- twitter: @BosNaufal
- telegram: @BosNaufal
