testing

Dari 19 test yang harusnya hijau, 14 lulus. Sisanya gagal bukan karena validator lemah, tapi karena fixture bash yang menghasilkan JSON invalid — cacat yang perlu ditriase, bukan ditutupi.

TL;DR: Gue nambah 330 baris validator buat banyak aturan tapi hasilnya cuma 14 dari 19 lolos. Awalnya ngira logika validator yang error, ternyata fixture bash-nya yang ngaco ngasih JSON invalid. Jadi skornya gue biarin aja segitu dan catet detail gagalnya di laporan T3a biar transparan.

Validator yang terlalu sensitif menuduh data valid sebagai pelanggaran. Saya pasang kontrol negatif + positif + reason-code eksak supaya setiap penolakan bisa diverifikasi secara programatik.

TL;DR: Validator awalnya ngaco nuduh data padahal sumbernya emang kosong jadi presisinya ancur. Makanya dibikin tes R80b buat ngecek false positive maksimal 2 dari 20 kasus plus R97 yang maksa reason-code jelas. Ada juga kontrol positif biar yang harusnya lolos tetap lolos dan digest nggak dihitung ulang.

Suite hijau semua belum tentu bagus. Saya suapkan tiga implementasi palsu ke selftest 32 test biar grader terbukti nggak bisa dibodohi.

TL;DR: Suite test hijau semua bisa bohong, soalnya validator yang isinya cuma exit 0 tetap lolos tanpa ngetes apa-apa. Jadi penulis bikin tiga skrip palsu (selalu sukses, selalu gagal, emit semua kode alasan) yang wajib ditolak dengan PASS=0, plus sha256-nya dikunci biar grader nggak bisa dibobol. Ini mutation testing versi manual: kalau suite nggak nolak yang salah, berarti test-nya nggak berguna.

Kisah commit 6f5ae82: selftest 32 test sengaja dibikin gagal dulu untuk membekukan kontrak CLI, baru implementasinya ditulis sampai hijau.

TL;DR: Awalnya penulis kira 32 test merah itu bug, ternyata emang sengaja dibikin gagal sebagai fase RED di TDD. Kontrak CLI dibekukan dulu lewat test pakai varian batch-freeze, bukan TDD kanonik, biar nggak nyimpang pas ngoding. Jadi layar merah itu bukan tanda proyek bermasalah, tapi peta spesifikasi yang tinggal dikejar sampai hijau.