Kapan Simbol Go Layak Diekspor
Migrasi test ke paket eksternal memaksa keputusan ekspor: tiga pintu antara tulis-ulang jalur publik, ekspor nyata, dan export_test.go.
Ringkasan
Gak nyangka, mindahin test ke paket luar ternyata bisa jadi audit API gratis. Pas migrasi, fungsi internal yang minta diekspor justru nunjukin logika yang selama ini kependeman padahal berguna, kayak deteksi duplikat sama sanitasi XSS. Ada tiga jalan: tulis ulang test lewat jalur publik, ekspor beneran kalau emang bernilai, atau akalin pake export_test.go.
Waktu membaca diff commit pemindahan test importer, saya berhenti di bagian yang aneh: ada empat berkas produksi ikut berubah di commit yang seharusnya cuma memindahkan berkas test. Nama fungsi di modul import data berubah, dan pemanggilnya di beberapa berkas lain ikut disesuaikan.
Dugaan pertama saya sederhana: pindah test tidak akan menyentuh kode produksi. Batch sebelum membuktikan itu, nol simbol diekspor, semua test ditulis ulang lewat jalur publik. Saya menyangka batch ini akan sama. Kenyataannya, empat fungsi justru diekspor sungguhan.
storeMediaFile -> StoreMediaFile
isDuplicateEntry -> IsDuplicateEntry
buildFullDescription -> BuildFullDescription
moduleMap -> ModuleMapSemua pemanggil di kode produksi diperbarui sekaligus.
Aturan ekspor dan kontrak abadinya
Mekaniknya ketat dan sederhana. Menurut spesifikasi bahasa Go, sebuah identifier diekspor kalau karakter pertamanya huruf besar Unicode dan ia dideklarasikan di blok paket, nama field, atau nama method [1]. Sisanya tidak diekspor dan tak terlihat dari paket lain.
Kemampuan teknis bukan berarti alasan. Blog resmi Go menyarankan meminimalkan interface yang diekspor: pengguna cepat bergantung pada setiap type, function, variable, dan constant yang diekspor, dan itu jadi kontrak implisit yang harus dijaga selamanya atau program pengguna bisa rusak [2]. Style guide Google melengkapi: tipe yang hanya dipakai internal sebaiknya tetap tidak diekspor [3]. Satu huruf besar di depan nama adalah pintu yang susah ditutup lagi.
Di titik inilah batasan black-box dari migrasi test bekerja sebagai alat audit. Begitu test pindah ke paket eksternal, setiap fungsi internal yang dipakai test harus punya jawaban: lewat pintu mana ia diuji? Ada tiga pintu, dan pemilihannya menyingkap nilai API sungguhan.
Tiga pintu keputusan
Pintu pertama: tulis ulang test lewat jalur publik yang sudah ada. Ini yang terjadi di hampir semua batch migrasi. Test handler menembus router sungguhan, test helper kecil ter-cover begitu versi publik Create dan Get dipanggil. Nol perubahan kode produksi, dan itu tanda API publiknya sudah sehat.
Yang menarik justru di pintu integrasi. Helper integrasi lama menembus field database yang tidak diekspor langsung dari struct Importer. Versi baru menyuntikkan koneksi lewat utilitas test setup yang menerima objek koneksi database secara eksplisit, dan penyemaian data media diganti insert langsung. Test tidak lagi bergantung pada detail struct, dan struct bebas berubah tanpa merusak test.
Pintu kedua: ekspor nyata, karena fungsinya memang punya nilai API di luar test. Empat fungsi importer masuk kategori ini. Deteksi duplikat yang menangani kasus deadlock database, sanitasi deskripsi yang menutup celah XSS, penyimpanan file media dengan penjagaan path traversal. Logika seperti ini berdiri sendiri dan layak jadi bagian antarmuka publik modulnya, lengkap dengan pemanggil produksi yang ikut berpindah ke nama baru.
Pintu ketiga: berkas export_test.go sebagai katup terakhir. Kalau sebuah internal cuma dibutuhkan test dan tidak berharga untuk pemanggil lain, pola resminya adalah mengekspor ulang simbol itu dalam berkas test di dalam paket, seperti yang dipakai paket bufio di pustaka standar [4]. Niatnya jujur dan terkonsentrasi di satu tempat yang gampang diaudit.
Audit yang tidak direncanakan
Perbandingan antar batch membuat pelajarannya tajam. Batch yang nol ekspor berarti jalur publiknya sudah cukup. Batch yang butuh empat ekspor berarti di sana ada logika yang selama ini tersembunyi padahal berharga. Kebutuhan ekspor muncul persis di tempat fungsi punya nilai nyata di luar konteks test, bukan di tempat test malas.
Saya tidak berani mengklaim keempat nama baru itu bentuk final API terbaiknya; penilaiannya baru teruji lewat pemakaian di produksi nanti. Yang pasti, sekarang setiap ekspor ada karena alasannya terdokumentasi di diff, bukan karena kebetulan akses test. Migrasi test berikutnya akan saya baca sebagai audit API gratis, sesuatu yang biasanya butuh sesi review khusus. Kalau auditnya menemukan nol temuan, itu pun kabar baik: API publiknya sudah cukup sehat.