Persen Cakupan Bukan Tameng: Amankan Jalur Penolakan
Audit cakupan middleware Go dari 27 ke 96,7 persen: pelajaran uji lengan penolakan dengan httptest, dari JWT sampai CORS.
Ringkasan
Cakupan test middleware cuma 27 persen padahal itu gerbang auth, jalur penolakan kayak token expired dan role mismatch nggak pernah disentuh test. Penulis nambahin 850 baris test ke tujuh file pakai httptest, tanpa ngubah kode produksi. Hasilnya middleware naik ke 96,7 persen, tapi pelajarannya: angka berhenti di tempat mock mulai bohong, yang penting tiap jalur risiko punya saksi.
Laporan audit cakupan malam itu saya gulir paket demi paket, dan satu barisnya berhenti lama di layar: middleware 27 persen. Paket yang justru jaga gerbang autentikasi. Lebih janggal lagi, jalur yang gelap bukan jalur ramai. Token kedaluwarsa, header hilang, peran tidak cocok, semuanya belum pernah disentuh satu pun pengujian. Kode penolakan itu berjalan tiap hari di produksi, cuma belum pernah dipanggil oleh test suite.
Refleks pertama saya keliru: menganggap 27 sebagai tantangan matematika. Tambah pengujian di mana saja, kejar dua digit depan, selesai. Saya nyaris menulis pengujian untuk jalur yang sudah tercakup supaya papan laporan terlihat sehat, padahal lengan berisiko justru yang kosong. Definisi angkanya sendiri sederhana: cakupan mengukur berapa banyak pernyataan kode yang dieksekusi saat pengujian berjalan [1]. Angka itu tidak tahu mana jalur berbahaya, ia cuma menghitung.
Satu Lengan, Satu Fungsi Pengujian
Pekerjaan yang benar ternyata lebih membosankan: berjalan lengan demi lengan. Komite audit menandai paket bercakupan tidak sehat, saya ambil urutan paling gelap, lalu 850 baris pengujian dibagi ke tujuh berkas baru. Setiap skenario penolakan dapat satu fungsi dengan httptest, pustaka bawaan Go untuk menguji handler HTTP: ResponseRecorder-nya mencatat mutasi http.ResponseWriter supaya bisa diperiksa kemudian, dan NewRequestWithContext menyusun permintaan sisi server tanpa socket asli [2].
Nama fungsinya sekalian jadi dokumen. TestJWTAuth_ExpiredToken mengunci respons token kedaluwarsa, TestRequireRole_MismatchedRole mengunci penolakan peran yang tidak cocok, TestRequiredUserAuth_AdminTokenRejected menutup celah token admin di gerbang pengguna biasa, dan TestResolveBidang_SourceError mengunci jalur sumber data gagal. Paket CORS mendapat bagian serupa: origin yang tidak cocok harus ditolak, wildcard berperilaku sesuai kontrak, preflight dijawab benar. Middleware Recover diuji memuntahkan 500 tanpa membocorkan detail panic, dan pencatatan status di middleware logging diuji agar angka yang sampai ke client sama yang tercatat. Di paket request, batas ParseInt dan seluruh jalur VisitorKey ikut ditutup, dari kunci normal sampai variasi input yang dulu cuma tebakan. Totalnya 850 baris pengujian di tujuh berkas baru, sisanya satu komentar yang dikoreksi dan satu indeks dokumentasi. Tak ada satu baris pun kode produksi yang berubah, dan justru itu poinnya: permukaan keamanannya sudah ada, yang hilang adalah saksi.
Angka Naik, Tapi Tidak Seragam
Hasilnya: middleware naik dari 27 ke 96,7 persen, request dari 50 ke 100 persen. rbac merangkak dari 6,3 ke 42,1 persen lalu berhenti; sisa lengennya butuh toko RBAC sungguhan, bukan tiruan, dan memaksakan angka di sana berarti menguji palsu. Paket database diam di 39,4 persen karena pembungkusnya memang harus bertemu MySQL nyata. Di sinilah pelajarannya: angka berhenti naik tepat di tempat pengujian tiruan mulai berbohong. Kalau persen adalah tujuan, dua paket terakhir itu gagal. Kalau tujuannya lengan berisiko terkunci, misi selesai, dan 96,7 hanyalah efek samping yang manis. Peta yang saya pakai berikutnya pun berubah: bukan persen per paket, tapi daftar lengan yang masih tanpa saksi, diurutkan dari yang paling sering dilanggar penyerang.
Perilaku keamanan kini punya saksi bernama. Mengubah respons CORS atau melonggarkan peran berarti menggugat satu fungsi pengujian yang spesifik, bukan sekadar mengubah kode di tempat sepi. Perbedaannya terasa saat review: pertanyaannya jadi konkret, pengujian mana yang harus ikut berubah.
Satu perbaikan kecil ikut menumpang: komentar di decodepath.go. Teks lamanya menyiratkan nilai seperti %252C tetap terenkode setelah lewat middleware. Kenyataannya chi sudah mendekode path sekali saat pencocokan rute, jadi yang diterima middleware sudah %2C. Komentar keliru di lengan keamanan itu racun pelan: pembaca berikutnya akan menulis kode untuk dunia yang tidak ada.
Kebiasaan yang saya bawa pulang: setiap kali menulis lengan penolakan baru, tulis pengujinya seketika dan panggil by name dengan flag -run milik go test [3]; flag itu menjalankan hanya pengujian yang cocok pola, jadi siklusnya cepat, dan induk yang ikut jalan pun tetap dilaporkan. Persen boleh naik sendiri setelahnya. Yang wajib dicek tetap satu: tiap jalur penolakan punya bukti eksekusi bernama.