TDD: A ‘Life Insurance’ for Codes!

4 min readMay 1, 2021

Dalam menjalani kehidupan, tentu saja kita akan melalui berbagai macam rintangan. Dari mulai rintangan yang terduga, hingga rintangan yang tidak terduga. Mungkin sebagian besar orang telah menyiapkan diri untuk menghadapi rintangan yang terduga, misalnya ketika seseorang mempersiapkan kompentensi diri untuk memasuki dunia profesional (bekerja). Lalu, bagaimana persiapan untuk menghadapi rintangan yang tidak terduga?

Asuransi merupakan fasilitas yang dapat memberikan beberapa benefits yang dapat digunakan oleh pengguna nya. Jadi, bisa dikatakan pengguna tidak perlu khawatir lagi jika mereka telah menggunakan asuransi. Namun, apakah asuransi hanya ada untuk menjalani kehidupan? Tidak begitu!

Asuransi yang akan kita bahas pada artikel ini adalah mengenai asuransi untuk code yang kita tulis. Hal ini biasa dikenal sebagai Test-Driven Development.

The Definiton.

Test-Driven Development adalah pendekatan dalam software development dimana test cases dikembangkan untuk menentukan serta memvalidasi apa yang akan dilakukan oleh code. Secara sederhana, test case akan diuji terlebih dahulu, untuk dijadikan sebagai acuan dalam membuat implementasi code yang baru. Jika pengujian tersebut gagal, maka code yang baru akan ditulis untuk mengimplementasikan hal yang di ekspektasikan oleh test cases. Sehingga, code yang dihasilkan nantinya adalah code yang sesuai dengan ekspektasi.

Source: from Giphy

Why TDD?

Seperti yang sudah saya jelaskan, TDD ini akan sangat berguna untuk kita sebagai software developer dalam menyusun code. Kira-kira, alasan apa saja yang membuat kita perlu melakukan TDD?

Kita tidak perlu pusing dalam implementasi code. Kita hanya perlu menuliskan satu unit test yang dijadikan sebagai acuan kita untuk fungsionalitas code nantinya.
TDD mampu menghindari kita dari bugs yang tidak terduga. Ya, tentu saja! Karena TDD berfokus kepada satu unit test dengan satu solusi untuk masing-masing unit test.
Kerapihan yang terjamin ketika kita menggunakan TDD sebagai pendekatan dalam software development. TDD mampu mengurangi penggunaan code yang tidak dibutuhkan, sehingga code akan terhindar dari dupliasi kode, bugs, dan mudah untuk dibaca. Mirip dengan clean code bukan?

Hmm. Berbicara soal clean code, apakah TDD merupakan bagian dari clean code? Menurut saya, ya. Clean code memiliki standar-standar tertentu yang dapat dipenuhi apabila kita menerapkan TDD dalam software development kita. Hal demikian bisa Anda akses melalui artikel yang telah saya tuliskan mengenai clean code, melalui tautan berikut ini.

How to TDD?

Untuk melakukan TDD, ada beberapa hal yang perlu kita ketahui agar perjalanan TDD kita berjalan dengan baik.

Project Knowledge. Kita perlu memahami fitur apa yang akan kita implementasikan. Misalnya pada pengerjana proyek PPL ini, kita perlu membaca dan memahami project backlog yang tertulis agar mengerti fitur apa yang diingkan oleh client, agar tidak terjadi miss pada saat menuliskan untaian kode.
Translate The Requests. Setelah berhasil memahami, langkah selanjutnya kita perlu mengartikan permintaan client menjadi beberapa implementasi test yang digunakan.
Do what requested. Bisa dibilang, ini langkah kita untuk melakukan implementasi apa yang kita telah artikan sebelumnya. Tuliskan code sesuai dengan apa yang diminta pada saat kita membuat unit test. Jangan menulis kode diluar yang diminta. Karena hal ini dapat menggagalkan proses TDD sekaligus menurunkan kualitas code kita.

The Phases.

Sederhananya, TDD memiliki tiga fase yang harus dilalui. Ketiga fase tersebut bisa dibilang sebagai jantung dari TDD. Artinya, suatu TDD berhasil dilakukan apabila ketiga fase tersebut dilalui dengan baik. Ketiga fase tersebut umumnya dikenal dengan sebutan RED-GREEN-REFACTOR. Dibalik 3 kata tersebut, tersimpan seribu makna yang penting untuk diketahui, yaitu:

RED, code yang dituliskan adalah code yang masih salah. Disini kita diharapkan untuk menuliskan expected implementation pada code yang ditulis. Berikut adalah salah satu contoh pada code project yang saya buat:

GREEN, pada fase ini, code yang dituliskan adalah implementasi dari ekspektasi yang telah dituliskan pada fase RED. Sehingga, akan menghasilkan valid coverage dan pipeline akan berwarna hijau.

REFACTOR, fase ini bisa dibilang sebagai fase koreksi. Misalnya kita berharap kita dapat memiliki code yang menghasilkan succeeded pipeline pada saat fase GREEN, tetapi yang terjadi adalah tetap RED. Atau bisa untuk melakukan pengubahan code dalam skala yang sangat kecil, misalnya hanya mengubah warna pada button, bukan major change seperti mengubah alur fitur.