Skip to content

Test Karakterisasi: Mencatat Perilaku, Bukan Menghakimi

Adityo Guni Waluyo

Test karakterisasi mengunci perilaku kode apa adanya saat keputusan pemilik produk belum jatuh, lengkap dengan marker pending.

Ringkasan

Test karakterisasi tujuannya bukan mastiin kode bener, tapi ngunci perilaku yang sekarang terjadi. Jadi assertion gagal artinya ada yang berubah, bukan rusak. Pas keputusan owner masih pending, test ini jadi pagar biar nggak ada yang ubah perilaku diam-diam.

Hari ini saya menjalankan ulang suite test untuk dua modul layanan. Ratusan baris output hijau lewat, lalu mata saya berhenti di satu tempat yang aneh: tepat di atas assertion, ada komentar literal // characterization: current behavior, owner decision pending. Test-nya lolos, tapi perilaku yang dikunci terasa janggal. Salah satu test itu menyatakan laporan per bidang itu sensitif terhadap huruf besar-kecil. Bukan keputusan, cuma catatan: begini perilakunya sekarang, dan seseorang perlu memutuskan nanti.

Tebakan saya yang salah soal nama "test"

Dulu saya mengira test karakterisasi adalah test yang memastikan kode benar. Namanya kan test, ya logikanya memverifikasi.

Ternyata keliru. Michael Feathers mendefinisikannya lewat tulisan Alberto Savoia: test karakterisasi "tidak memeriksa apa yang seharusnya dilakukan kode, seperti test spesifikasi, tapi apa yang benar-benar dan saat ini dilakukan kode" [1]. Fokusnya bukan kebenaran, tapi dokumentasi. Feathers menegaskan tujuannya: "mendokumentasikan perilaku aktual sistem Anda, bukan memeriksa perilaku yang Anda harapkan dimiliki sistem" [2].

Bedanya bukan cuma filosofis. Dengan test biasa, assertion gagal berarti ada yang rusak. Dengan test karakterisasi, assertion gagal berarti ada yang berubah. Titik. Apakah perubahan itu baik atau buruk, itu keputusan terpisah yang bukan tugas test.

Prosedurnya sengaja memakai kegagalan

Prosedur Feathers yang direkam Savoia terdengar seperti badut: tulis assertion yang sengaja gagal, jalankan, "biarkan kegagalan memberi tahu Anda apa perilaku sebenarnya", ganti ekspektasi dengan nilai aktual, ulangi [1]. Kenapa tidak langsung menulis nilai yang benar? Karena kita sering tidak tahu. Nilai "benar" itu justru yang sedang dipertanyakan. Kegagalan pertama adalah alat pengukur, bukan kecelakaan.

Di suite yang saya baca tadi, polanya kelihatan di beberapa titik: validasi nama bidang dengan batas per karakter, penghitungan panjang notifikasi yang dihitung dari byte tanpa pemangkasan, kolom catatan yang tidak pernah dibersihkan antar tahap alur, subjek tiket publik yang muncul tanpa awalan kode bidang. Empat perilaku, empat marker pending, satu kalimat yang sama: keputusan menunggu pemilik produk.

Perilaku yang terkunci itu sendiri belum tentu benar. Feathers bilang, "kalau Anda belum memastikan bahwa perilaku yang Anda temukan itu bug, sering kali ide bagus membiarkan test itu tetap di tempatnya" [2]. Membetulkan bug adalah commit terpisah yang sadar dirinya mengubah satu assertion. Yang dilarang adalah mengubah perilaku diam-diam lewat refactor.

Kenapa menunda keputusan butuh test, bukan cuma komentar

Komentar "tanya owner dulu" tidak menghentikan siapa pun. Test yang lolos di CI menghentikan siapa pun. Selama marker itu pending, test berperan sebagai pagar: siapa pun yang mengubah perilaku harus membuka assertion itu dan mengetahui bahwa ada keputusan yang belum jatuh.

Martin Fowler menyebut suite seperti ini jaring pengaman: dengannya kita bisa merapikan kode dengan aman karena "pendeteksi bug akan berbunyi" saat kita salah langkah, dan kepercayaan itulah yang membuat kita berani mengubah sistem [3]. Bagi kode dengan area abu-abu seperti punya saya, jaring itu bukan kemewahan. Ia yang memungkinkan keputusan ditunda tanpa proyek berubah menjadi telusur regresi.

Satu hal yang saya pegang dari kejadian hari ini: menunda keputusan bukan tanda proyek tidak sehat. Yang tidak sehat adalah keputusan yang tertunda tapi tidak ada yang menjaga perilakunya. Test karakterisasi plus marker pending adalah cara membuat penundaan itu eksplisit, terjaga, dan punya alamat jelas: kapan pun owner memutuskan, ada satu assertion yang menunggu diubah, dan satu commit yang jujur mengaku melakukannya.

Sumber

  1. Alberto Savoia, "Working Effectively With Characterization Tests" (artima.com)
  2. Michael Feathers, "Characterization Testing" (michaelfeathers.silvrback.com)
  3. Martin Fowler, "Self Testing Code" (martinfowler.com)

Artikel terkait