Tutorial
4 mnt bacaAdmin

Membuat Test dengan AI: Checklist agar Test Tidak Sekadar Hijau

AI bisa membuat draft test dengan cepat, tapi kita tetap perlu memastikan test-nya benar-benar mengunci behavior.

#AI#Format: Checklist#AI Coding#Testing
islupTutorial

AI bisa membantu membuat test lebih cepat. Ia bisa membaca fungsi, menebak skenario, membuat mock, dan memberi contoh unit test atau integration test.

Tapi test dari AI punya satu risiko besar: kelihatan rapi, hijau, tapi tidak benar-benar menguji behavior penting.

Test seperti itu memberi rasa aman palsu. Build lolos, angka coverage naik, tapi bug tetap bisa lewat karena test hanya mengecek hal yang terlalu dangkal.

Checklist ini membantu memakai AI untuk membuat test yang lebih berguna.

1. Jelaskan behavior yang harus dijaga

Sebelum meminta test, jelaskan dulu behavior yang ingin dikunci.

Prompt:

Saya ingin membuat test untuk fungsi ini.
Behavior yang harus dijaga:
- menerima input email valid
- menolak email kosong
- menolak format email salah
- mengembalikan pesan error yang bisa ditampilkan di UI

Tolong buat daftar skenario test dulu, jangan langsung kode.

Langkah ini penting. Kalau AI langsung membuat kode test, ia sering hanya mengikuti struktur fungsi, bukan kebutuhan produk.

2. Minta daftar skenario sebelum kode

Biasakan meminta daftar skenario dulu.

Skenario minimal:

  • happy path
  • input kosong
  • input salah format
  • data tidak ditemukan
  • permission ditolak
  • error dari dependency
  • edge case data panjang
  • regresi bug yang pernah terjadi

Prompt:

Tolong buat matriks test:
- nama skenario
- input
- expected output
- alasan test ini penting

Setelah daftar skenario masuk akal, baru minta kode test.

3. Pastikan test tidak mengulang implementasi

Test yang buruk sering hanya menyalin logika dari fungsi yang dites.

Misalnya fungsi menghitung diskon, lalu test juga menghitung diskon dengan rumus yang sama. Kalau rumus salah, test tetap bisa hijau karena salahnya ikut disalin.

Minta AI mengecek:

Tolong pastikan test ini mengecek output yang diharapkan, bukan mengulang implementasi fungsi.
Kalau ada test yang terlalu mirip dengan kode produksi, tandai.

Test yang baik menguji hasil dan behavior, bukan menyalin isi fungsi.

4. Minta edge case yang realistis

AI kadang memberi edge case yang terlalu umum. Misalnya selalu menyebut null, undefined, empty string. Itu berguna, tapi tidak cukup.

Minta edge case yang sesuai domain.

Contoh untuk artikel:

  • slug duplikat
  • meta description terlalu panjang
  • artikel scheduled tanpa tanggal
  • tag kosong
  • content berisi heading ganda

Contoh untuk form:

  • spasi di awal dan akhir
  • email huruf besar
  • submit dua kali
  • koneksi gagal
  • response lambat

Prompt:

Tolong beri edge case yang spesifik untuk domain artikel CMS, bukan edge case generik saja.

5. Pisahkan unit test dan integration test

AI sering mencampur semua hal. Padahal unit test dan integration test punya tujuan berbeda.

Unit test cocok untuk:

  • fungsi kecil
  • validator
  • formatter
  • parser
  • helper

Integration test cocok untuk:

  • server action
  • API route
  • flow database
  • proses login
  • publish artikel

Prompt:

Pisahkan rekomendasi test menjadi:
1. unit test
2. integration test
3. manual checklist

Jelaskan mana yang paling penting dibuat dulu.

Dengan begitu, kamu tidak membuang waktu membuat test berat untuk hal yang cukup dicek kecil.

6. Cek mock yang dibuat AI

Mock bisa membantu, tapi mock yang salah membuat test tidak bermakna.

Cek:

  • apakah mock terlalu ideal?
  • apakah error dependency dites?
  • apakah data mock mirip data asli?
  • apakah relasi yang wajib ada ikut dibuat?
  • apakah mock menyembunyikan bug integrasi?

Prompt:

Tolong review mock di test ini.
Cari apakah mock terlalu sederhana sehingga bug asli bisa tidak ketahuan.

Untuk database, pastikan data test mencerminkan relasi nyata. Kalau artikel selalu punya author, mock juga harus punya author.

7. Kunci bug yang pernah terjadi

Setiap bug yang pernah lolos adalah kandidat test yang bagus.

Prompt:

Bug sebelumnya:
[jelaskan bug]

Tolong buat test regresi yang gagal sebelum fix dan hijau setelah fix.

Test regresi lebih bernilai daripada test umum karena ia menjaga bug yang nyata pernah terjadi.

8. Minta checklist manual untuk UI

Tidak semua hal mudah diotomasi. Untuk UI, AI bisa membantu membuat checklist manual.

Contoh checklist:

  • buka di desktop
  • buka di mobile
  • coba data kosong
  • coba teks panjang
  • klik tombol dua kali
  • cek loading state
  • cek error state
  • cek console browser

Prompt:

Buat checklist QA manual untuk fitur ini.
Fokus pada mobile, state kosong, state error, teks panjang, dan interaksi tombol.

Checklist ini sangat berguna saat fitur belum punya test UI otomatis.

9. Review test seperti review kode produksi

Test juga bisa punya bug. Jangan menerima test dari AI begitu saja.

Cek:

  • apakah test bisa gagal saat behavior rusak?
  • apakah assertion cukup spesifik?
  • apakah nama test jelas?
  • apakah test terlalu bergantung pada implementasi?
  • apakah setup terlalu rumit?

Kalau test selalu hijau meski kode produksi diubah menjadi salah, test itu tidak berguna.

Template prompt membuat test

Saya ingin membuat test untuk kode ini:
[tempel kode]

Konteks behavior:
[jelaskan tujuan fitur]

Tolong lakukan bertahap:
1. Buat daftar skenario test.
2. Tandai mana yang wajib.
3. Baru tulis test untuk skenario wajib.
4. Jelaskan cara menjalankannya.
5. Beri checklist manual jika ada bagian UI.

Jangan membuat test yang hanya mengulang implementasi.

Kesimpulan

Membuat test dengan AI bisa menghemat waktu, tapi kualitas test tetap harus diarahkan. Mulai dari behavior, minta skenario dulu, cek edge case, dan pastikan test bisa menangkap bug nyata.

Test yang bagus bukan sekadar hijau. Test yang bagus membuat kita lebih berani mengubah kode karena behavior penting sudah terkunci.

Ditulis oleh

i

Admin

Tim editorial islup.com

Catatan teknologi ditulis untuk cepat dipindai, enak dibaca, dan tetap bisa dipraktikkan. Fokusnya bukan teori panjang, tapi keputusan kecil yang membantu kerja harian.

Sumber & pengecekan

Biar artikelterpercaya.

01

Praktik langsung

Ditulis dari pola kerja dan percobaan yang relevan.

02

Rujukan resmi

Dokumentasi resmi dipakai saat membahas fitur, versi, atau aturan.

03

Cek ulang

Klaim teknis dan langkah penting dicek agar tidak menyesatkan.

Detail artikel

Dipublish: 28 Juni 2026

Durasi baca: 4 mnt baca

Tipe: Tutorial

Catatan sumber

Jika artikel menyebut harga, versi software, kebijakan platform, atau data yang bisa berubah, gunakan tautan resmi di dalam artikel sebagai rujukan utama.

Lanjut baca

Cara Mengecek Jawaban AI: Jangan Langsung Percaya, Pakai Checklist Ini

AI bisa mempercepat kerja, tapi bukan berarti semua jawabannya benar. Biasakan cek sebelum dipakai.

Feedback

Artikel ini membantu?

Masukan kecil dari pembaca bantu kami menjaga artikel tetap jelas dan praktis.

Diskusi

Tinggalkan komentar

Baca Juga

Tutorial terkait