Teknik Unit Testing Aplikasi Web
“Rejection is superstition”
- Dr. Eng Moh. Ivan Fanany
Izinkan saya memperkenalkan diri pada blog post pertama yang saya buat pada blog ini. Nama saya Yudhis, peran saya adalah developer dalam tim Energizer-AAA.
Blog post yang saya buat kali ini dan kedepannya, dibuat berdasarkan pengalaman selama mengembangkan aplikasi web bersama tim Energizer-AAA.
Aplikasi web frontend sudah pasti menggunakan bahasa pemrograman javascript. Apabila aplikasi frontend yang Anda kembangkan tidak menggukan javascript, mungkin bisa dikatakan bahwa Anda menggunakan cara yang tidak standar.
Tentunya Anda sebagai developer ingin solusi yang mudah dan tidak merepotkan. Kalau ada, Anda pasti mau menggunakan library unit testing yang mana Anda hanya perlu mengcopy-paste user story ke code.
Ada dua testing framework populer untuk keperluan front end testing, yaitu Mocha dan Jest. Kelebihan mocha adalah Anda dapat dengan fleksibel memilih library untuk assertion, mock, spy, snapshot, functional testing, dll. Mungkin bagi sebagian orang, hal tersebut bisa dianggap sebagai kekurangan. Apabila Anda termasuk orang yang menganggap hal tersebut sebagai kekurangan, maka Anda akan dengan senang hati menggunakan framework Jest — developer tidak perlu menginstall library tambahan lagi, Jest sudah menyediakan semuanya.
Mana contoh konkritnya?
Sebagai contoh, anggap kita sedang mengembangkan halaman job listing dengan react, “JobListingPage”. Komponen JobListingPage ini akan diberikan sebuah property berupa fungsi “fetchJobListing” yang bertujuan untuk memuat data job listing. Tentunya, karena yang kita lakukan adalah unit testing, maka seharusnya yang kita test hanya salah satu, yaitu antara JobListingPage atau fetchJobListing. Pada contoh kali ini, saya berikan cara test JobListingPage.
Karena kita ingin melakukan test pada komponen JobListingPage, maka seharusnya fungsi fetchJobListing yang digunakan pada test bukanlah fungsi fetchJobListing yang sesungguhnya. Apabila kita menggunakan fungsi fetchJobListing yang sesungguhnya, artinya kita menguja dua komponen, yaitu JobListingPage dan fetchJobListing. Padahal yang ingin kita test hanyalah JobListingPage. Maka dari itu, fungsi fetchJobListing yang kita gunakan ketika melakukan test pada komponen JobListingPage adalah fungsi bohongan — mock function.
jest.fn() adalah API untuk menghasilkan mock function. Dalam kasus ini, fetchJobListing yang diberikan ke JobListingPage haruslah berupa mock. Karena behaviour yang diharapkan adalah JobListingPage harus memanggil fungsi fetchJobListing ketika selesai dirender, maka pada code testing kita tulis semacam “expect fakeFetcher to be called 1 time(s)”. Di sini terlihat kehebatan Jest, syntax unit testing dibuat sedemikian rupa agar sangat mudah dipahami oleh developer lain yang tidak menulis code testing terkait.
Bagian “shallow” pada contoh code unit test bertujuan untuk merender component react JobListingPage pada environment unit test. Selain melakukan rendering, function shallow juga akan mengaktifkan lifecycle component react. Karena shallow akan mengaktifkan lifecycle component react, maka kita sebagai penulis unit test dapat beranggapan dengan kuat bahwa seharusnya fungsi fetchJobListing benar-benar akan dipanggil dalam environment unit test ini, jika implementasi JobListingPage sudah benar.
Kita sudah membuat sebuah unit test terkait behaviour tertentu, lalu apa langkah selanjutnya? Apakah kita akan membuat unit test terkait behaviour yang lain?
Tentu tidak. Dalam metode test-driven development, ketika kita selesai membuat sebuah unit test terkait behaviour tertentu, langkah selanjutnya adalah mengimplementasikan komponen terkait agar memenuhi unit test yang baru saja kita buat. Setelah itu baru kita buat unit test lain, dan kemudian
Sesuai judul blog posting ini, saya pun tak akan membahas cara untuk mengimplementasikan JobListingPage agar memenuhi unit test yang saya lampirkan di atas.
Begini lah kurang lebih cara kami, tim Energizer-AAA, melakukan unit test pada aplikasi web frontend. Saya harap Anda mendapat insight baru setelah membaca tulisan ini.
See you later
Bonus: Unit Test Backend
Frontend tidak akan bekerja tanpa backend, maka ada baiknya cara unit test backend disisipkan di sini. Pertama, unit test akan ditampilkan terlebih dahulu karena “TDD”
Method setUp akan dipanggil tepat sebelum setiap kali method unit test dipanggil. Ini membuat kode unit test menyesuaikan prinsip DRY: Don’t repeat yourself. Tanpa ada fitur ini, prinsip DRY agak repot untuk dicapai.
Decorator @ patch akan melakukan mock pada module terkait. Hal ini harus dilakukan supaya unit test bersifat isolated.
Selain itu, sudah dipastikan bahwa setiap unit test hanya menguji satu hal, atau dengan kata lain “one assertion per unit test”. Ini dilakukan untuk menyesuaikan panduan Clean Code dari buku Clean Code oleh Robert Martin.
Kode implementasi menerapkan dua design pattern, yaitu Singleton dan Dependency Inversion. Kedua design pattern ini penting agar unit test mudah dituliskan. Selain itu, kedua design pattern ini harus sudah dipikirkan sebelum menulis test. Jadi urutan kerjanya: pikirkan design pattern -> tulis unit test dengan asumsi bahwa implementasi menerapkan design pattern yang terpikirkan -> implementasi.
