Apa itu TDD (Test-Driven Development)? Menulis Tes Sebelum Menulis Kode

Logika Terbalik yang Membingungkan Pemula

Alur kerja normal seorang *Developer* adalah: Membaca tugas fitur dari atasan → Menulis kode (If-Else/Looping) → Selesai dan dirilis → Jika perusahaan rajin, barulah di akhir mereka menulis skrip Automated Testing (Unit Test).

Tapi, ada sebuah mazhab radikal dalam Software Engineering bernama TDD (Test-Driven Development). Mazhab ini memaksa kita untuk bekerja mundur: TULIS DULU SKRIP TES-NYA SEBELUM KAMU MENGETIK KODE ASLINYA!

Alur Suci TDD: Red - Green - Refactor

TDD dibangun di atas siklus disiplin berulang yang dikenal dengan 3 tahap warna (biasanya menggunakan library penguji seperti Jest atau PHPUnit).

1. RED (Merah - Gagal)

Bos menyuruhmu membuat fungsi KalkulatorPajak(). Di TDD, kamu DILARANG menulis fungsi kalkulatornya. Kamu WAJIB langsung menulis Skrip Tes Otomatisnya.
"Wahai Jest, tolong ekspektasikan jika aku memasukkan harga 100 dan pajak 10%, fungsi Kalkulator harus menghasilkan angka 110."
Saat kamu menekan tombol *Run Test*, layar terminalmu akan menyala Merah (Error). Tentu saja error, karena fungsi kalkulatornya belum ada di alam semesta!

2. GREEN (Hijau - Berhasil Seadanya)

Sekarang barulah kamu diizinkan menyentuh *text editor*. Tugasmu di fase Hijau adalah: Tulis kode sejelek dan secermat mungkin, YANG PENTING tes warna merah tadi berubah jadi Hijau (Lolos Tes). Tidak perlu memikirkan kode yang bersih atau elegan, hanya penuhi tuntutan si Robot Penguji (Jest).

3. REFACTOR (Merapikan Kode)

Sekarang kodemu sudah lolos ujian (*Green*). Barulah kamu masuk ke fase perbaikan. Kamu membersihkan variabel sampah, mempersingkat perulangan, dan membuat kodenya elegan (Clean Code).
Kekuatan supernya? Saat kamu merombak kodenya menjadi lebih rapi, kamu bisa menekan tombol *Run Test* berkali-kali. Jika warnanya masih hijau, kamu tahu dengan yakin 100% bahwa kamu tidak merusak sistem!

Mengapa TDD Sangat Dihormati?

Pemula membenci TDD karena terasa memperlambat pekerjaan (butuh waktu mengetik skrip ujian). Namun Senior *Engineer* di perusahaan Finansial / Bank mewajibkan TDD karena satu alasan: Desain Berorientasi Bug-Free.

Dengan menulis Tes sebelum kode dibuat, pikiran sang *programmer* dipaksa untuk membayangkan segala Edge Case (Kondisi aneh/Error) terlebih dahulu. Kodemu akan dirancang kebal peluru sejak lahir, dan masa depan perusahaanmu terjamin aman dari kehancuran tak disengaja (Regression Bug).