Refactoring and Testing Implemented in Auto Personalia

Berikut adalah hal menyangkut refactoring dan testing yang pernah saya lakukan di Auto Personalia.

Refactoring

Refactoring adalah proses restrukturisasi kode program tanpa mengubah perilaku eksternalnya. Proses ini dilakukan untuk meningkatkan readability, mengurangi kompleksitas, memudahkan maintenance, dan memperbaiki keterluasan program. Istilah refactoring dipopulerkan oleh Martin Fowler.

Dalam Auto Personalia, refactoring yang saya lakukan salah satunya adalah terkait dengan database, yakni tabel permit_histories.

Pada awalnya, tabel permit_histories memiliki salah satu atribut approval_status yang dapat bernilai ‘0’ atau ‘1’ (boolean). Ketika bernilai ‘1’, berarti izin yang diajukan oleh karyawan sudah disetujui oleh HR dan karyawan dapat melihat status pengajuan izinnya menjadi ‘disetujui’. Namun ketika bernilai ‘0’, apakah status pengajuan yang akan ditampilkan ke karyawan tersebut?

Tidak ada pembeda yang jelas antara status yang telah ditolak atau masih menunggu persetujuan HR. Oleh karena itu, saya memutuskan untuk melakukan refactoring pada database. Tipe refactoring yang saya lakukan adalah replacing column permit_histories. Replacement dari column tersebut juga bertujuan untuk mengganti DataTypes dari approval_status dengan ENUM(‘disetujui’, ’menunggu persetujuan’, ‘ditolak’).

Selain itu, saya juga melakukan refactoring untuk mengambil approval_status dari tiap entri tabel status pengajuan izin untuk ditampilkan di modal. Fungsi yang saya buat pada awalnya kadang berfungsi, kadang tidak. Hal ini saya prediksi karena entri pada tabel tidaklah statis, namun dapat berubah-ubah sesuai pengajuan sehingga fungsi tidak dapat berjalan secara stable. Oleh karena itu, saya mengubah fungsinya agar dicek di js setiap kali entri dipilih yang berada pada folder public. Lebih jelasnya, dapat dicek di pipeline PPLB3.

Test Driven Development / TDD

Test Driven Development adalah proses pengembangan yang mengharuskan para developer-nya untuk membuat tes, baru mengimplementasi kodenya. Sebenarnya, apa sih keuntungan dari TDD? Saya pribadi merasa bahwa TDD ini membantu kita dalam memenuhi kriteria minimal pemenuhan dari suatu kode. Maksudnya, dengan membuat tes terlebih dahulu, kita secara tidak langsung menentukan hal-hal fungsional apa saja yang harus kita cover lewat kode yang kita buat. Jika kita langsung coding tanpa memiliki kriteria minimal pemenuhan kode, kita bisa saja lupa dengan kriteria-kriteria yang kita inginkan (misalnya: tidak bisa menerima input huruf) dan kemudian menyelesaikan kode dengan seadanya saja (asal jalan) tanpa menguji ulang kode tersebut.

Lalu, apa kekurangan TDD? Dari pengalaman kelompok kami, awalnya akan sulit untuk menentukan bagaimana caranya memulai membuat testing. Karena kesulitan itu, kami seringkali tergoda untuk mengimplementasi kodenya dibanding untuk membuat testing. Namun berhubung salah satu rekan kelompok kami sangat bersemangat untuk membuat semua testing memiliki coverage 100%, kami pun terpancing untuk lebih tekun dan tabah dalam membuat testing. Bravo, PPLB3! :’)

Dalam pengerjaannya, walaupun awalnya membuat testing terasa seperti suatu beban, saya merasa sangat terbantu, khususnya ketika membuat suatu kode, saya tidak perlu lagi melakukan testing secara manual dan mengingat test case-nya satu per satu. Ketika muncul test case baru, saya hanya perlu menuliskannya di kode testing, kemudian voila! Test case tersebut akan selalu diuji jika saya melakukan perubahan pada kode dan menjalankan perintah npm test pada kode saya.

Jadi, enak ga sih TDD? Yaah, semua hal di dunia ini memang ada baik buruknya, sama halnya dengan TDD. Dalam pengerjaan proyek yang relatif kecil atau berjangka pendek, TDD mungkin terasa tidak perlu. Akan tetapi, dampak dalam jangka panjangnya TDD pasti akan menghemat alokasi waktu dalam testing.