Test Driven Development or Test Slows Development
Kenapa sih sebenernya harus menerapkan metode TDD? Bikin test casenya lama tapi hasil ngoding codenya bagi client kayaknya nggak ada.
Test-driven development (TDD) (Beck 2003; Astels 2003), is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.
Sebelum membahas mengapa harus menulis test dulu sebelum menuliskan code code implementasi, coba baca pengalaman saya ini.
Working Code Dulu, Test Kemudian
Pengerjaan tugas mata kuliah Proyek Perangkat Lunak, Digipus, sudah berjalan selama lebih dari 2 bulan. Jenuh, lelah, kehilangan semangat udah dirasakan dalam masa-masa pengembangan ini. Akhirnya saat sedang mengerjakan fitur baru dalam Digipus, terpikir untuk lansung menuliskan codenya saja tanpa menuliskan test casenya dulu. Selesai menuliskan code implementasinya, langsung push ke Git deh hasilnya. Eh tapi kan peraturannya harus TDD, berarti tinggal tulis testnya deh biar nanti pas penilaian bilangnya TDD, kan ada file testnya. Akhirnya mulai deh nulis test case untuk fitur baru yang sudah dikembangin.
Baru mulai nulis test langsung terasa masalah masalahnya.
- Code yang udah ditulis rasanya lebih kompleks dari yang seharusnya dibuat
- Code yang udah ditulis sulit sekali untuk ditest. Beberapa kali harus ubah implementas supaya bisa ditest.
- Karena error terus testnya, dan menghabiskan banyak waktu, akhirnya nggak nulis testnya sama sekali.
Tapi penilaiannya harus ada testnya biar bisa keliatan TDD, jadi? TDD makanya.
Apa sih TDD?
Singkatnya tulis test case terhadap aplikasi yang akan dibuat, lalu kembangkan aplikasinya berdasarkan test case yang sudah dibuat sebelumnya. Ada 3 tahap dalam menerapkan metode TDD dalam pengembangan suatu aplikasi.
RED — Sebelum menulis kode, tuliskan test-nya terlebih dahulu. Pastikan kita memasukkan semua kemungkinan yang dapat kita pikirkan untuk input dan outputnya. Jalankan test-nya, dan pastikan test-nya fail karena belum ada kode apapun untuk membuat test-nya pass. Berikut contohnya ketika saya push commit yang testnya masih fail. Fitur yang saya kembangkan saat itu adalah fitur menambahkan komentar. Salah satu test yang saya buat saat itu adalah melakukan POST terhadap form yang masih belum diisi.
GREEN — Tulis implementasi code seminimum mungkin dengan tujuan agar test-nya pass. Jalankan test dan cek apakah test-nya sudah OK atau pass. Jika belum, maka perbaiki implementasi code kita sampai memenuhi ekspektasi dari test. Pada fitur form tersebut, setelah menuliskan test dan sudah failed, saya sudah bisa mengimplementasikan seminimal mungkin hanya untuk membuat testnya sudah tidak failed lagi.
REFACTOR — Lengkapi implementasi code hingga memenuhi kebutuhan pengembangan aplikasinya tanpa merubah expected behavior dari fitur yang sedang dikerjakan. Dengan begitu test yang sudah kita buat akan tetap OK/pass. Berikut code pada tahap refactoring.
Dengan menerapkan metode ini, banyak manfaat yang dapat kita peroleh. Beberapa manfaat yang saya rasakan saat menerapkan TDD pada pengerjaan Digipus antara lain
- Penerapan TDD membantu dalam mengembangkan aplikasi dengan jauh lebih produktif, yaitu sedikit demi sedikit namun dengan kualitas yang sangat baik.
- Membantu membatasi fungsionalitas sesuai dengan yang dibutuhkan, sehingga waktu yang digunakan tidak habis untuk menuliskan code code yang sebenarnya tidak dibutuhkan.
- Kalau ada masalah dalam implementasi, test yang ada menolong kita mengetahui bagian mana yang sebenarnya menyebabkan kesalahan. Dengan begitu saya tidak perlu mencari kesalahan pada ratusan baris code, menghabiskan waktu berjam-jam dengan emosi untuk mencari kesalahan bodoh yang dibuat.
3 manfaat penggunaan metode TDD tadi sangat membantu saya dalam menjaga produktifitas dalam pengembangan aplikasi Digipus ini.
So, masih pengen nulis implementasi dulu baru nanti bikin testnya? Pikir dulu baik-baik.
ref:
