Apa Itu RED dalam TDD? Red-Green-Refactor

Apa Itu RED dalam TDD? Memahami Red-Green-Refactor dari Dasar sampai Praktik

Jumat, pukul 16.47. AI coding agent melaporkan fitur selesai. Diff-nya rapi. Semua test berwarna hijau. Developer tinggal menekan tombol merge.

Ada satu detail yang tidak terlihat dari laporan itu. Agent menulis test setelah implementasi selesai, lalu menyesuaikan hasil yang diharapkan dengan kode yang sudah dibuat. Test lulus, tetapi business rule tetap salah. Warna hijau memberi rasa aman tanpa bukti yang kuat.

Engineer yang sehat tidak langsung mengejar GREEN. Ia lebih dulu membuktikan bahwa test dapat gagal saat behavior belum tersedia. Dalam Test-Driven Development, fase itu disebut RED.

RED bukan gangguan yang harus disembunyikan. RED adalah kontrol awal. Ia membedakan test yang benar-benar memeriksa behavior dari test yang hanya mengesahkan kode.

Banyak orang memahami TDD sebagai "menulis banyak test". Padahal inti TDD adalah memakai test untuk mengarahkan desain dan implementasi secara bertahap. Siklusnya sederhana:

Tulis satu test untuk behavior yang belum ada.
Jalankan test sampai hasilnya RED.
Tulis kode paling sederhana agar test menjadi GREEN.
Refactor kode tanpa mengubah behavior.
Ulangi siklus untuk behavior berikutnya.

Artikel ini menjelaskan apa itu RED, apa itu TDD, hubungan RED dengan GREEN dan REFACTOR, contoh praktik dengan TypeScript dan Vitest, serta cara memakai AI coding agent tanpa menjadikan test sebagai formalitas.

Jawaban singkat: RED adalah fase dalam siklus TDD ketika test yang baru ditulis gagal karena behavior yang diminta belum tersedia. TDD adalah pendekatan pengembangan software yang menulis dan menjalankan test lebih dulu, lalu memakai hasil test itu untuk mengarahkan implementasi.

Apa itu RED dalam TDD?

RED adalah keadaan ketika test gagal setelah kita menulis test untuk behavior baru.

Contoh kebutuhan:

Pengguna mendapat gratis ongkir jika subtotal belanja mencapai Rp150.000.

Sebelum menulis fungsi, kita tulis ekspektasi tersebut sebagai test. Ketika test dijalankan, implementasi belum ada atau belum benar. Test gagal. Hasil itu disebut RED.

RED memiliki dua fungsi utama:

menunjukkan bahwa test benar-benar dapat mendeteksi behavior yang belum tersedia;
memberi titik awal yang jelas untuk implementasi berikutnya.

RED bukan berarti semua test dalam project harus gagal. RED hanya berlaku pada test yang sedang kita tambahkan atau ubah. Test lain yang sudah ada seharusnya tetap GREEN.

RED juga bukan singkatan resmi dari kata tertentu. Dalam istilah Red-Green-Refactor, RED merujuk pada warna yang biasa dipakai test runner untuk menandai kegagalan test.

RED bukan test yang rusak

Test gagal karena dua alasan yang berbeda:

Behavior belum benar. Test berjalan dan assertion gagal. Ini RED yang berguna.
Test atau environment rusak. Ada syntax error, import salah, dependency belum terpasang, atau konfigurasi test gagal. Ini bukan bukti bahwa behavior sudah diuji.

Keduanya sama-sama dapat tampil sebagai error. Developer harus membaca penyebabnya.

RED yang sehat biasanya memiliki ciri berikut:

test bisa dijalankan oleh test runner;
assertion menunjukkan hasil aktual dan hasil yang diharapkan;
kegagalan berhubungan langsung dengan behavior yang baru diminta;
test akan menjadi GREEN setelah implementasi yang benar dibuat.

Kalau test berhenti karena SyntaxError, kita belum sampai pada validasi behavior. Perbaiki masalah setup tersebut dahulu. Setelah test berjalan dan assertion gagal karena fitur belum ada, barulah kita memiliki RED yang bermakna.

Apa itu TDD?

TDD adalah singkatan dari Test-Driven Development. Dalam Bahasa Indonesia, istilah ini dapat diterjemahkan sebagai pengembangan software yang diarahkan oleh test.

Pada proses biasa, developer sering melakukan urutan berikut:

menulis kode implementasi;
mencoba kode secara manual;
menulis test jika ada waktu atau jika bug muncul.

Pada TDD, urutannya dibalik:

pahami behavior yang dibutuhkan;
tulis test untuk behavior tersebut;
jalankan test dan pastikan test gagal dengan alasan yang tepat;
tulis implementasi minimum;
jalankan test sampai lulus;
rapikan kode;
lanjut ke behavior berikutnya.

TDD bukan sekadar teknik QA. Test menjadi alat untuk membahas kebutuhan, membentuk interface, dan mengarahkan desain kode. Karena itu, TDD sering disebut sebagai teknik desain yang memakai test sebagai umpan balik cepat.

Martin Fowler merangkum TDD sebagai pengulangan tiga aktivitas: menulis test untuk fungsi berikutnya, menulis kode sampai test lulus, lalu melakukan refactor. Agile Alliance juga menjelaskan bahwa coding, unit testing, dan desain melalui refactoring saling terkait dalam TDD.

Referensi:

Red-Green-Refactor: tiga langkah inti TDD

1. RED: tulis test yang gagal

Mulai dari satu behavior kecil.

Jangan langsung menulis seluruh test untuk satu modul besar. Pilih satu aturan yang dapat diamati.

Contoh:

Jika subtotal kurang dari Rp150.000, pengguna tidak mendapat gratis ongkir.

Atau:

Jika subtotal tepat Rp150.000, pengguna mendapat gratis ongkir.

Test yang baik membuat behavior tersebut dapat dibaca tanpa membuka implementasi.

2. GREEN: tulis kode paling sederhana

Setelah test gagal, tulis kode minimum yang membuat test lulus.

"Minimum" bukan berarti asal-asalan. Artinya, jangan membangun abstraksi, konfigurasi, atau optimasi yang belum dibutuhkan oleh behavior saat ini.

Pada tahap awal, implementasi yang sangat sederhana bahkan boleh terlihat kurang lengkap. Test berikutnya akan memaksa desain berkembang. Yang perlu dijaga adalah behavior yang sudah disepakati tetap lulus.

Agile Alliance memakai istilah "just enough code". Tujuannya adalah menjaga fokus pada behavior, bukan menebak semua kebutuhan masa depan.

3. REFACTOR: rapikan tanpa mengubah behavior

Setelah test GREEN, periksa kode dan test.

Refactor dapat berupa:

mengganti nama fungsi agar lebih jelas;
memecah fungsi yang terlalu panjang;
menghapus duplikasi;
menyederhanakan kondisi;
memperbaiki struktur module;
memperbaiki nama test;
memindahkan helper ke lokasi yang tepat.

Setelah setiap perubahan, jalankan test lagi. Jika test tetap GREEN, kita memiliki bukti bahwa refactor tidak mengubah behavior yang sudah diuji.

Banyak implementasi TDD berhenti di GREEN. Ini kesalahan umum. Tanpa refactor, codebase dapat berubah menjadi kumpulan patch kecil yang semuanya punya test, tetapi sulit dibaca dan sulit dikembangkan. Test memberi perlindungan. Refactor menjaga bentuk kode.

Kenapa test yang gagal justru dibutuhkan?

Dalam pekerjaan software, kegagalan biasanya ingin dihilangkan secepat mungkin. TDD memakai kegagalan secara berbeda.

RED memberi informasi yang belum kita miliki: test yang ditulis belum dapat dipenuhi oleh kode saat ini.

Informasi ini berguna karena:

kita tahu test benar-benar dijalankan;
kita tahu behavior belum tersedia;
kita dapat melihat bentuk interface dari sisi pemakai;
kita memiliki target implementasi yang konkret;
kita mencegah implementasi berjalan tanpa definisi hasil yang diharapkan.

Tanpa RED, developer mudah menulis test setelah implementasi lalu tanpa sadar menyesuaikan test dengan kode yang sudah dibuat. Test bisa terlihat rapi, tetapi tidak lagi menjadi pemeriksaan yang independen terhadap behavior.

RED juga membantu menemukan test yang tidak berguna. Jika test langsung GREEN sebelum implementasi dibuat, beberapa kemungkinan perlu diperiksa:

behavior memang sudah tersedia;
test salah menunjuk fungsi atau environment;
assertion terlalu lemah;
test tidak benar-benar menjalankan kode;
test menguji hal yang sudah ada, bukan behavior baru.

Test yang langsung lulus tidak otomatis salah. Namun dalam TDD, kita harus tahu mengapa test itu lulus.

Contoh TDD dengan TypeScript dan Vitest

Contoh berikut memakai TypeScript dan Vitest. Aturannya sederhana:

Gratis ongkir berlaku jika subtotal belanja minimal Rp150.000.

Langkah pertama: tulis test

Buat file shipping.test.ts.

import { describe, expect, it } from 'vitest'
import { isEligibleForFreeShipping } from './shipping'

describe('isEligibleForFreeShipping', () => {
 it('returns true when subtotal reaches the minimum', () => {
 expect(isEligibleForFreeShipping(150_000)).toBe(true)
 })
})

Pada tahap ini, file shipping.ts belum dibuat. Jika test langsung dijalankan, test runner dapat berhenti karena module belum ditemukan. Itu adalah masalah setup, bukan assertion RED yang ideal.

Buat stub minimum agar test dapat dieksekusi:

export function isEligibleForFreeShipping(_subtotal: number): boolean {
 return false
}

Sekarang test berjalan dan gagal dengan alasan yang jelas:

Expected: true
Received: false

Inilah RED yang kita cari.

Langkah kedua: buat implementasi minimum

Ubah shipping.ts menjadi:

const FREE_SHIPPING_MINIMUM = 150_000

export function isEligibleForFreeShipping(subtotal: number): boolean {
 return subtotal >= FREE_SHIPPING_MINIMUM
}

Jalankan test lagi. Test menjadi GREEN.

Pada titik ini, kita belum boleh menyimpulkan bahwa semua aturan gratis ongkir sudah benar. Kita baru membuktikan satu behavior: subtotal tepat Rp150.000 menghasilkan true.

Langkah ketiga: tambah behavior berikutnya

Tambahkan test untuk subtotal di bawah minimum:

import { describe, expect, it } from 'vitest'
import { isEligibleForFreeShipping } from './shipping'

describe('isEligibleForFreeShipping', () => {
 it('returns false when subtotal is below the minimum', () => {
 expect(isEligibleForFreeShipping(149_999)).toBe(false)
 })

 it('returns true when subtotal reaches the minimum', () => {
 expect(isEligibleForFreeShipping(150_000)).toBe(true)
 })
})

Jalankan test. Jika implementasi memakai subtotal >= 150_000, kedua test tetap GREEN.

Tambahkan kasus batas lain jika aturan bisnis membutuhkannya:

it('returns false for zero subtotal', () => {
 expect(isEligibleForFreeShipping(0)).toBe(false)
})

Apa yang terjadi jika hanya ada satu test?

Dengan satu test yang hanya memeriksa subtotal Rp150.000, implementasi yang salah seperti ini dapat lulus:

export function isEligibleForFreeShipping(_subtotal: number): boolean {
 return true
}

Itulah sebabnya jumlah test bukan ukuran yang cukup. Test harus membedakan behavior yang benar dari behavior yang salah.

Test untuk nilai di bawah batas membuat implementasi selalu true gagal. Test untuk nilai tepat di batas memastikan aturan minimum tidak dibuat terlalu ketat.

Refactor pada contoh tersebut

Konstanta FREE_SHIPPING_MINIMUM membuat aturan lebih mudah dibaca dan menghindari angka yang tersebar di kode. Refactor ini tidak mengubah behavior.

Jika aturan minimum harus berasal dari konfigurasi, kita dapat mengubah desain setelah test memberi kebutuhan yang jelas. Jangan memasukkan configuration service, database, dan cache hanya karena mungkin dibutuhkan nanti.

TDD, unit test, integration test, dan end-to-end test

Istilah TDD sering tercampur dengan jenis test. Keduanya berbeda.

TDD adalah cara mengembangkan software.
Unit test menguji bagian kecil dari kode secara terisolasi.
Integration test menguji hubungan beberapa komponen, misalnya service dengan database.
End-to-end test menguji alur dari sudut pandang pengguna, misalnya membuka halaman checkout sampai pembayaran selesai.

TDD paling sering dipraktikkan dengan unit test karena unit test cepat memberi feedback. Namun pendekatan test-first juga dapat dipakai untuk integration test atau acceptance test, dengan konsekuensi waktu dan biaya yang lebih besar.

Jangan mengganti semua validasi dengan unit test. Sebuah fungsi dapat lulus unit test, tetapi gagal saat terhubung ke database, queue, payment gateway, browser, atau konfigurasi production.

Gunakan beberapa lapisan test sesuai risiko:

unit test untuk aturan dan transformasi yang dapat diuji cepat;
integration test untuk kontrak antar-komponen;
end-to-end test untuk alur bisnis yang paling penting;
manual exploratory test untuk behavior yang sulit dijelaskan dengan script;
monitoring dan alert untuk masalah yang hanya terlihat setelah sistem live.

TDD membantu membangun lapisan tersebut. TDD tidak menghapus kebutuhan untuk memeriksa sistem secara menyeluruh.

Apa bedanya TDD dengan menulis test setelah coding?

Perbedaannya bukan hanya urutan waktu. Fokus dan umpan baliknya juga berbeda.

Test setelah coding

Developer membuat implementasi lebih dahulu. Setelah itu, developer menulis test berdasarkan kode yang sudah ada.

Cara ini tetap dapat menghasilkan test yang bagus. Banyak project tidak dimulai dengan TDD dan tetap memiliki test suite yang berguna.

Risikonya adalah test mengikuti struktur internal, bukan behavior yang ingin dijaga. Developer juga dapat melewatkan kasus yang tidak terpikir saat implementasi.

TDD

Developer menulis test berdasarkan behavior yang diinginkan sebelum implementasi dibuat. Test memaksa developer memikirkan cara fungsi akan dipakai.

Keuntungannya adalah interface dan hasil yang diharapkan dibahas lebih awal. Kekurangannya, TDD membutuhkan disiplin, latihan, dan waktu untuk memilih test yang tepat.

TDD bukan alasan untuk merendahkan test yang ditulis setelah coding. Ukur kualitas dari kemampuan test menemukan bug, menjelaskan behavior, dan memberi feedback yang cepat.

Cara memakai TDD saat menggunakan AI coding agent

AI coding agent dapat menulis implementasi dalam hitungan detik. Itu membuat TDD semakin penting, bukan semakin tidak perlu.

Tanpa test-first, agent dapat menghasilkan kode yang:

terlihat masuk akal tetapi tidak sesuai business rule;
mengubah banyak file untuk fitur kecil;
menambahkan dependency tanpa alasan;
membuat test yang hanya mengulang implementasi;
menghapus atau melemahkan assertion agar suite menjadi GREEN;
menutupi error dengan try/catch atau fallback yang tidak diminta;
mengklaim selesai tanpa menjalankan test yang relevan.

Gunakan agent dalam loop yang eksplisit.

Prompt tahap RED

Minta agent melakukan satu pekerjaan kecil:

Baca struktur repository dan aturan yang relevan. Untuk behavior berikut:
"Gratis ongkir berlaku jika subtotal minimal Rp150.000."

Tulis satu atau dua test yang mendeskripsikan behavior tersebut.
Jangan mengubah production code.
Jalankan test.
Laporkan command, hasil gagal, dan alasan kegagalannya.
Jika test berhenti karena setup error, perbaiki setup minimum tanpa mengubah behavior.
Jangan menunggu input atau meminta approval interaktif.

Output yang diharapkan adalah test yang gagal karena behavior belum ada. Bukan laporan bahwa agent sudah membuat fitur.

Prompt tahap GREEN

Setelah RED terbukti:

Implementasikan kode paling sederhana yang membuat test baru menjadi GREEN.
Jangan mengubah test kecuali ada kesalahan spesifikasi yang jelas.
Jangan menambah dependency atau abstraksi yang belum diperlukan.
Jalankan test yang baru dan test terkait.
Laporkan file yang berubah dan hasil command secara exact.

Prompt tahap REFACTOR

Setelah test GREEN:

Review perubahan untuk refactor kecil yang aman.
Pertahankan behavior dan assertion.
Hapus duplikasi atau nama yang membingungkan jika memang ada.
Jangan menambah fitur baru.
Jalankan ulang test setelah refactor.
Jika tidak ada refactor yang perlu, katakan demikian.

Guardrail untuk AI-assisted TDD

Sebelum menerima perubahan dari agent, periksa hal berikut:

Test baru muncul sebelum implementasi pada riwayat perubahan atau pada langkah kerja yang terdokumentasi.
Test gagal sebelum implementasi dibuat.
Kegagalan terjadi karena behavior yang belum tersedia, bukan karena konfigurasi yang rusak.
Implementasi membuat test GREEN tanpa menghapus assertion.
Test lama tetap GREEN.
Test mencakup kasus normal dan setidaknya satu boundary atau failure case yang relevan.
Agent tidak mengubah test hanya untuk menyesuaikan hasil kode.
Diff tetap berada dalam scope fitur.
Command test dapat dijalankan ulang oleh developer lain.
CI menjalankan test tersebut sebelum merge.

Test adalah evidence. Kalimat "test sudah dibuat" bukan evidence. Evidence adalah command yang dijalankan, hasilnya, dan diff yang dapat diperiksa.

Kesalahan umum saat menerapkan TDD

Menulis terlalu banyak test sekaligus

TDD bekerja dengan feedback pendek. Jika kita menulis 30 test sebelum menjalankan satu pun, kita kehilangan manfaat feedback tersebut.

Mulai dari satu behavior. Jalankan. Lanjutkan.

Membuat test terlalu besar

Test yang menjalankan seluruh aplikasi dapat lambat dan sulit dibaca. Jika gagal, penyebabnya tidak langsung jelas.

Pecah test berdasarkan behavior yang dapat diamati. Simpan test integration atau end-to-end untuk batas yang memang perlu diuji.

Menguji detail implementasi

Test yang memeriksa private method, urutan pemanggilan internal, atau nama variable akan mudah rusak saat kode di-refactor.

Uji hasil dan behavior yang penting bagi pemakai. Test seharusnya tetap GREEN saat struktur internal berubah tetapi behavior tetap sama.

Mengejar code coverage sebagai tujuan utama

Code coverage menunjukkan bagian kode yang disentuh oleh test. Coverage tidak membuktikan bahwa assertion sudah tepat.

Sebuah test tanpa assertion dapat menaikkan coverage tanpa memeriksa hasil. Sebuah assertion yang terlalu longgar juga tidak memberi perlindungan.

Microsoft Learn mengingatkan bahwa persentase coverage yang tinggi tidak otomatis menunjukkan kualitas kode yang tinggi. Coverage berguna sebagai sinyal. Ia bukan acceptance criteria tunggal.

Menggunakan mock terlalu banyak

Mock dapat mengisolasi dependency, tetapi mock yang berlebihan membuat test mengikuti detail internal. Test juga dapat tetap GREEN ketika integrasi nyata sudah rusak.

Gunakan mock untuk batas eksternal yang mahal, tidak stabil, atau sulit dipanggil dalam unit test. Tambahkan integration test untuk membuktikan kontrak dengan dependency penting.

Mengabaikan refactor

Test yang lulus tidak membuat desain otomatis baik. TDD tetap membutuhkan keputusan teknis, penamaan, struktur module, dan review manusia.

Jika kode mulai sulit dibaca, berhenti menambah behavior. Refactor dahulu. Jalankan test. Baru lanjutkan.

Kapan TDD layak dipakai?

TDD cocok ketika behavior dapat ditulis sebagai input dan output yang jelas. Contohnya:

aturan harga dan diskon;
validasi form;
parser dan formatter;
perhitungan pajak atau ongkir;
permission dan authorization;
transformasi data;
API contract;
workflow status;
bug yang dapat direproduksi;
fungsi yang akan sering berubah.

TDD juga berguna saat codebase memiliki risiko regression tinggi. Test kecil dapat menjadi pagar sebelum perubahan lebih besar dilakukan.

Kapan TDD tidak perlu dipaksakan?

TDD bukan ritual yang harus dipakai dengan bentuk sama untuk semua pekerjaan.

Pertimbangkan pendekatan lain atau kombinasi pendekatan jika:

kebutuhan masih sangat eksploratif;
UI masih berupa prototype yang sering berubah;
behavior belum cukup jelas untuk ditulis sebagai assertion;
pekerjaan hanya berupa konfigurasi sederhana;
nilai test tidak sebanding dengan waktu penulisannya;
sistem membutuhkan exploratory testing untuk menemukan masalah yang belum diketahui.

Pada kondisi ini, buat spike atau prototype untuk memahami masalah. Setelah behavior mulai stabil, tambahkan test pada bagian yang memiliki risiko dan nilai paling tinggi.

Prinsipnya bukan "semua harus TDD". Prinsipnya adalah: tulis bukti yang sesuai dengan risiko sebelum perubahan sulit dikembalikan.

Checklist praktis Red-Green-Refactor

Gunakan checklist berikut untuk satu perubahan kecil:

Sebelum coding

Behavior apa yang ingin ditambahkan?
Input apa yang valid?
Hasil apa yang diharapkan?
Kasus batas apa yang berisiko?
Test apa yang paling kecil untuk membuktikannya?

RED

Test sudah ditulis sebelum implementasi?
Test dapat dijalankan?
Test gagal karena behavior belum tersedia?
Pesan error menunjukkan expected dan received value?

GREEN

Implementasi hanya mencakup kebutuhan saat ini?
Test baru lulus?
Test terkait yang lama tetap lulus?
Tidak ada assertion yang dihapus atau dilemahkan?

REFACTOR

Nama fungsi dan test mudah dipahami?
Ada duplikasi yang perlu dihapus?
Ada abstraksi yang belum diperlukan?
Test tetap lulus setelah refactor?

Sebelum merge

Diff sudah direview?
Unit test dan integration test yang relevan sudah dijalankan?
CI lulus?
Acceptance criteria sudah terbukti?
Jika perubahan menyentuh data atau security, apakah ada verifikasi tambahan?

FAQ: pertanyaan tentang RED dan TDD

Apakah RED adalah metode testing?

Bukan. RED adalah fase pertama dalam siklus Red-Green-Refactor. TDD adalah pendekatan pengembangan software yang memakai test sebagai pengarah implementasi.

Apakah RED berarti kode kita buruk?

Tidak. Dalam TDD, RED yang terkontrol berarti behavior baru belum diimplementasikan dan test berhasil mendeteksi kondisi tersebut.

Apakah test harus selalu gagal sebelum kode ditulis?

Untuk behavior baru yang sedang dikembangkan dengan TDD, ya. Test perlu gagal atau belum dapat dipenuhi sebelum implementasi dibuat. Namun kegagalan karena syntax error atau konfigurasi rusak bukan RED yang berguna.

Apa arti GREEN dalam TDD?

GREEN berarti test yang sedang dikerjakan lulus setelah implementasi dibuat. Targetnya adalah menulis kode paling sederhana yang memenuhi behavior yang diuji.

Apa arti REFACTOR dalam TDD?

REFACTOR berarti merapikan struktur kode atau test tanpa mengubah behavior. Test yang tetap GREEN menjadi pengaman selama proses tersebut.

Apakah TDD sama dengan unit testing?

Tidak. TDD adalah cara kerja. Unit testing adalah jenis test. TDD sering memakai unit test karena feedback-nya cepat, tetapi test-first juga dapat dipakai pada integration test dan acceptance test.

Apakah TDD menjamin software bebas bug?

Tidak. TDD meningkatkan feedback dan dapat membantu mencegah regression, tetapi hasilnya bergantung pada kualitas test, ketepatan behavior, cakupan risiko, serta validasi lain seperti integration test dan monitoring.

Apakah code coverage tinggi berarti TDD berhasil?

Tidak. Coverage hanya menunjukkan bagian kode yang disentuh test. TDD membutuhkan test yang memeriksa behavior dengan assertion yang berarti.

Apakah TDD masih berguna jika memakai AI coding agent?

Ya. AI dapat mempercepat penulisan kode, tetapi test tetap dibutuhkan untuk memeriksa apakah kode sesuai behavior. Dengan TDD, agent diberi batas kerja yang lebih jelas: buktikan RED, buat GREEN, lalu refactor tanpa mengubah evidence.

Kesimpulan operasional

RED adalah fase yang sengaja dicari dalam TDD. Test ditulis lebih dahulu, lalu dijalankan untuk membuktikan bahwa behavior baru belum tersedia. Setelah itu, developer membuat implementasi minimum sampai test GREEN. Refactor menjaga kode tetap sehat.

Nilai TDD tidak terletak pada banyaknya file test. Nilainya terletak pada feedback yang cepat, behavior yang jelas, dan bukti yang dapat diulang.

Untuk pekerjaan dengan AI coding agent, pola ini menjadi semakin penting. Agent boleh menulis kode dengan cepat. Ia tetap harus menunjukkan test yang gagal sebelum implementasi, test yang lulus setelah implementasi, dan hasil verifikasi setelah refactor.

Mulai dari satu behavior kecil. Tulis test. Jalankan sampai RED. Buat GREEN. Refactor. Ulangi.

Kembali ke laporan agent pada awal artikel. Semua test bisa tampak GREEN dan tetap gagal melindungi business rule. Karena itu, minta bukti RED sebelum menerima GREEN.

Kode yang cepat dibuat belum tentu siap dipakai. Kode yang disertai evidence lebih mudah dipercaya, direview, dan dirawat.