Triase Merah 14 dari 19: Saat Fixture Bash yang Cacat Menipu Validator

Layar terminal saya menampilkan hasil yang cukup mengejutkan: triase merah 14 dari 19. Commit bc77087 baru aja selesai dieksekusi. Saya baru saja menambahkan 330 baris perintah check dan init di hermes/scripts/ingest-blueprint.py. Cakupannya cukup luas, mencakup aturan R75 sampai R79, R82 sampai R88, serta R93, R94, R99, R100, R103, R104, dan R105 dengan flag --close. Harapannya sederhana, semua test harus hijau. Kenyataannya, ada lima aturan yang gagal total.

Insting pertama saya langsung menuduh logika validator. Saya buka file itu, mencari-cari di mana kondisi edge case yang terlewat. Mungkin parsing JSON-nya terlalu ketat? Atau ada variabel lingkungan yang nggak kebaca saat inisialisasi? Saya habiskan waktu lumayan lama ngecek ulang logika kondisional di sekitar aturan yang bermasalah. Rasanya ada yang salah di cara saya menyusun validasi.

Tapi setelah saya isolasi test yang gagal dan melihat output mentahnya, tebakan saya meleset. Masalahnya bukan di validator. Masalahnya ada di fixture bash. Transform fixture yang saya pakai untuk lima aturan gagal itu ternyata menghasilkan output JSON yang invalid atau sekadar no-op. Validator saya sebenarnya bekerja dengan sempurna. Ia menolak data rusak karena data yang masuk emang rusak sejak awal.

Ini adalah momen yang mengajarkan saya satu hal penting tentang arsitektur testing. Fixture itu ibarat fondasi rumah. Kalo fondasinya miring, nggak peduli seberapa bagus desain rumahnya, semuanya akan terlihat retak. Prinsip Fresh Fixture dalam pengujian perangkat lunak menekankan bahwa setiap test harus membangun fixture barunya sendiri untuk mencegah Erratic Tests [1]. Ketika sebuah fixture kelas cacat menghasilkan JSON invalid, test itu bukan lagi menguji logika bisnis, melainkan menguji ketahanan parser terhadap sampah.

Saya punya pendapat tegas soal ini. Lebih baik test gagal secara reliabel daripada test yang flaky [4]. Test yang gagal karena fixture rusak setidaknya memberi sinyal jelas bahwa ada yang salah di lingkungan pengujian. Test yang flaky, yang kadang lolos kadang gagal tanpa alasan jelas, jauh lebih berbahaya karena merusak kepercayaan tim terhadap seluruh suite pengujian.

Untuk memastikan ini bukan halusinasi, saya cek dokumentasi pytest. Framework ini emang mengizinkan fixture yang sama diminta oleh dua test berbeda, dan masing-masing akan mendapatkan instance hasilnya sendiri [3]. Tapi ada catch-nya. Kalo proses setup fixture raise exception atau menghasilkan data korup, teardown mungkin nggak akan berjalan dengan bersih, dan test akan gagal dengan cara yang membingungkan.

Dalam kasus saya, fixture bash itu gagal melakukan transformasi yang diharapkan. Alih-alih memberikan payload JSON yang valid untuk diuji, ia melempar string kosong atau format yang nggak ter-parse. Validator saya, yang dirancang untuk ketat, langsung menolaknya. Ini adalah bukti nyata bahwa kegagalan tersebut bukan bug logika validator, melainkan masalah lingkungan uji.

Lalu gimana solusinya? Opsi paling godaan adalah mengedit test suite agar melewati aturan ini, atau memaksa fixture agar lolos dengan data dummy yang nggak realistis. Saya menolak melakukan itu. Mengubah test hanya agar berwarna hijau adalah anti-pola yang merusak integritas pengujian jangka panjang.

Sebagai gantinya, saya mengambil keputusan untuk membekukan suite pengujian ini. Skor tetap dicatat sebagai 14 dari 19. Analisis defek lengkap mengenai lima aturan yang gagal ini saya dokumentasikan secara terpisah di laporan T3a. Dengan cara ini, siapa pun yang melihat repositori di masa depan akan tahu persis kenapa angka itu nggak sempurna. Transparansi ini jauh lebih berharga daripada angka yang direkayasa.

Istilah triase merah biasanya dipakai di dunia medis untuk kondisi yang butuh penanganan segera. Dalam konteks pipeline pengujian saya, ini adalah sinyal untuk berhenti sejenak dan mengevaluasi ulang asumsi. Saya sempat mengira validator saya yang lemah. Ternyata, justru kekakuan validator itulah yang menyelamatkan saya dari menerima data cacat sebagai data valid.

Ke depannya, sebelum menulis ratusan baris logika validasi baru, saya akan memastikan pipeline pembuatan fixture bash udah diverifikasi secara independen. Menguji validator dengan data uji yang rusak sejak awal hanya akan membuang waktu.

Sources

• [1] xUnit Test Patterns: Fresh Fixture — xunitpatterns.com
• [2] xUnit Test Patterns: Testcase Class per Fixture — xunitpatterns.com
• [3] pytest documentation: Fixtures — docs.pytest.org
• [4] Google Testing Blog, Flaky Tests at Google (John Micco, 2016), archived 2026-01-01 — archive.org