Ringkasan Utama
Test-driven development memberi AI coding agent sesuatu yang tidak bisa dibantahnya: sebuah test yang gagal yang mendefinisikan selesai. Tulis test-nya dahulu, konfirmasi bahwa mereka gagal, minta agen tidak menyentuhnya, lalu biarkan ia menulis kode hingga semuanya lolos. Test itu menjadi spesifikasi yang dapat dieksekusi sekaligus verification loop bawaan.
AI coding agent itu cepat, percaya diri, dan sesekali salah dengan cara yang tampak benar. Mereka dengan senang hati menyerahkan kode yang bisa dikompilasi, enak dibaca, dan diam-diam salah menangani satu input yang lupa Anda sebutkan. Test-driven development adalah pertahanan tertua dan termurah terhadap mode kegagalan itu.
Idenya tidak berubah dari TDD klasik, tetapi imbalannya lebih besar dengan seorang agen dalam loop. Sebuah test suite adalah spesifikasi yang tidak bisa dielakkan agen dengan kata-kata, dan sebuah run yang hijau adalah sinyal yang bisa dikejarnya sendiri. Panduan ini menelusuri alur kerjanya dan di mana ia paling menguntungkan.
Mengapa TDD sangat cocok untuk agen
Seorang agen bekerja paling baik ketika ia punya target jelas dan cara memeriksa kemajuannya sendiri. Sebuah test yang gagal adalah keduanya sekaligus: ia menyatakan perilaku yang diharapkan secara presisi dan memberi sinyal lolos atau gagal yang tak ambigu setelah setiap perubahan.
Dibanding prompt berupa prosa, test menghapus ambiguitas yang jika tidak akan diisi agen dengan tebakan. Tiga sifat membuatnya ideal:
- Test dapat dieksekusi, sehingga agen mendapat umpan balik dalam hitungan detik tanpa menunggu Anda meninjau apa pun.
- Test itu presisi, sehingga perilaku yang dimaksud tertangkap sebagai input dan output konkret alih-alih kata sifat yang bisa ditafsir ulang agen.
- Test itu tahan lama, sehingga mereka terus menjaga perilaku itu lama setelah agen berpindah ke tugas berikutnya.
Loop red-green dengan seorang agen
Panduan best-practices Claude Code merekomendasikan urutan TDD yang konkret: minta agen menulis test dari input dan output yang diharapkan, jalankan untuk memastikan mereka gagal, commit test-nya, lalu minta agen mengimplementasi hingga setiap test lolos. Instruksi kuncinya adalah agen tidak boleh mengubah test agar menjadi hijau.
Mulailah dengan menulis test merah itu sendiri, atau minta agen membuat draftnya dan tinjau sebelum Anda memercayainya. Sebuah contoh kecil yang tak ambigu menetapkan nadanya:
// invoice.test.ts — write this FIRST, watch it fail
import { describe, it, expect } from "vitest";
import { calcLateFee } from "./invoice";
describe("calcLateFee", () => {
it("charges 1.5% per month on an overdue balance", () => {
expect(calcLateFee(1000, 2)).toBe(30);
});
it("returns 0 when nothing is overdue", () => {
expect(calcLateFee(1000, 0)).toBe(0);
});
});Commit test-nya sebelum agen menulis implementasi apa pun. Sebuah test yang sudah di-commit adalah kontrak yang beku, dan jika agen kemudian melemahkannya Anda akan melihat perubahan itu di diff alih-alih menemukannya di produksi.
Apa yang perlu diuji lebih dulu
Arahkan agen ke jalur kode tempat keluaran AI paling lemah, bukan happy path yang sudah benar dikerjakannya. Menurut Skyramp, kode yang dihasilkan AI menunjukkan tingkat cacat yang jauh lebih tinggi di area tertentu, dan area itulah tempat test pertama Anda seharusnya berada.
- Error handling, tempat Skyramp melaporkan tingkat cacat sekitar 3,4 kali lebih tinggi pada kode buatan AI, jadi uji jalur kegagalan sebelum jalur keberhasilan.
- Edge case, tempat Skyramp melaporkan sekitar 4,1 kali lebih banyak cacat, jadi liput input kosong, batas, dan null secara eksplisit.
- Concurrency, tempat Skyramp melaporkan sekitar 4,7 kali lebih banyak cacat, jadi uji jalinan eksekusi yang jarang dibayangkan agen sendiri.
- Sambungan integrasi, tempat sebuah unit yang lolos secara terisolasi tetap patah melawan database, queue, atau API pihak ketiga yang sungguhan.
Menjaga agen tetap jujur
TDD hanya berfungsi jika test tetap bermakna. Seorang agen yang tertekan untuk membuat sebuah suite lolos kadang mengambil jalan pintas yang tidak Anda maksudkan, dan tanda centang hijau menyembunyikannya.
Waspadai agen yang menyunting assertion, menghapus kasus yang menyulitkan, atau meng-hardcode nilai persis yang diharapkan sebuah test. Masing-masing mengubah test sungguhan menjadi stempel karet, jadi meninjau diff test sama pentingnya dengan meninjau implementasi.
Sebuah suite yang lolos itu perlu, tetapi tidak cukup. Seorang agen bisa membuat setiap test hijau dengan melemahkan test-nya, jadi jangan pernah menerima run yang hijau tanpa membaca apa yang berubah di dalam berkas test itu sendiri. Perlakukan setiap suntingan pada test yang sudah di-commit sebagai tanda bahaya.
Menempatkan TDD dalam alur kerja yang lebih besar
TDD adalah satu tahap dalam alur kerja agen yang disiplin, bukan keseluruhannya. Ia terselip secara alami di antara perencanaan dan review, dan pipeline seperti Superpowers menyusun tahap-tahapnya persis dalam urutan itu.
- Tentukan spesifikasi dahulu, menyepakati perilaku dalam bahasa biasa sebelum satu test pun ada, sehingga test mengkodekan hal yang benar.
- Tulis dan bekukan test-nya, pastikan mereka gagal, dan commit sebagai kontrak untuk perubahan itu.
- Biarkan agen mengimplementasi melawan suite itu, beriterasi hingga setiap test lolos tanpa menyentuh test-nya.
- Tinjau diff-nya, termasuk test, dan tambahkan edge case yang terlewat sebelum Anda merge.
TDD mengubah seorang AI agent dari penebak yang percaya diri menjadi sistem yang harus membuktikan hasil kerjanya. Tulis test yang gagal, bekukan, dan buat agen mendapatkan hijaunya. Ini adalah disiplin yang sama yang membuat TDD berharga bagi manusia, dan ia makin penting, bukan makin kurang, ketika kode ditulis oleh sebuah mesin.