Basic Debugging 101 — Android Studio
Waktu kalian ngoding, pasti ga jarang ketemu bug, mau bug tampilan, bug data, atau bug flow algoritma. Biasanya kalian ngapain kalo kodingan kalian ada bug? Banyak cara untuk nyari penyebab bug buat kita perbaiki, aktivitas tersebut biasa disebut debugging.
Hal yang paling mudah saat debugging tuh ngasih comment di line yang bug, buat mastiin misal kalo line itu ga dijalanin, masih bug apa engga.
Bisa juga pake log untuk memastikan isi sebuah variabel, atau untuk memastikan line tersebut terpanggil.
Tapi gimana kalo kita ga nemu line mana yang error? Atau bug yang sampe buat kita mikir, “ko bisa method ini kepanggil ya? padahal kan di flow nya ga ada yang manggil”. Pernah ga kalian nyoba debugging pakai line breakpoint?
Ayo sekarang coba perhatikan, IDE jaman sekarang ngasih fitur buat langsung run program yang lagi kita kerjakan (dulu mah kalo mau build harus compile sendiri, run pake command sendiri). Selain run program, ada juga run with debug, yang memungkinkan kita buat debug program waktu lagi berjalan menggunakan line breakpoint.
Fungsi line breakpoint tuh, buat ngepause program (suspend thread) tepat sebelum line yang ditandai dieksekusi. Saat program terpause, kita bisa lihat bahkan mengubah variabel-variabel yang ada, melihat thread yang berjalan, dan menjalankan kode perintah tersendiri.
Kira-kira penjelasannya kaya gitu. Banyak cara memanfaatkan breakpoint debugging, nah saya mau share nih contoh kasus yang sering saya temuin buat memakai line breakpoint, silakan disimak ya!
Validation Control
Waktu aplikasi kita udah diintegrasiin sama backend, sering banget screen aplikasi yang ditampilin bergantung sama state dari backend. Misal screen login, ada state untuk login gagal, login berhasil, mungkin setelah berhasil login ada validasi ke screen mana tergantung level / role tertentu, dsb. Dengan line breakpoint, kita bisa mengubah state yang kita dapet biar bisa langsung kita tes validasi yang udah dibuat.
Daripada kelamaan minta backend buat ubah level akun saya, langsung aja saya ubah state di mobile, dari login gagal, jadi login sukses level user, terus jadi login sukses level admin. Jadi tahu deh hasil validasi state saya ternyata berhasil.
Flow Tracing
Kalau ada beberapa code yang action nya mirip, biasanya dibuat method biar bisa direuse dan code jadi lebih bersih. Tapi kalo ada error / bug flow yang mengarah ke method tersebut, kita bakal jadi susah buat cari tahu siapa nih yang bikin bug / error. Kalau udah kaya gitu, saya pasti ngandalin breakpoint buat ngetrace flow program saya, bahkan bisa ngintip thread-thread yang sedang berjalan juga.
Ketahuan deh, dari sekian banyak yang akses onError, ternyata kasus saya yang manggil onError si method onLoginResponse di presenter.
Evaluate Expression
Pernah ga sih waktu di tengah running program, pengen ngerun suatu code / bahkan method yang ada buat mastiin efek code tersebut? Kita bisa loh ngelakuin hal kaya gitu. Waktu breakpoint nya lagi jalan, kalian klik aja button evaluate expression, atau Alt+F8 kalau di Android Studio.
Swipe refresh nya belum saya kasih action tuh waktu on refresh, jadi loading mulu waktu saya swipe. Nah saya pengen ngehide dulu itu loading, sekalian nampilin toast kalau code saya udah jalan.
Dummy Dataset
Kasus ini biasa saya temuin waktu ngerjain tampilan list. Pernah saya develop suatu list pakai 1 data mockup doang, nah pas udah dites sama QA, ternyata hasil kerjaan saya masih ada bug tampilan waktu datanya banyak, waktu teks nya panjang, waktu size gambar nya kecil, dll.Nah buat ngehindarin bug seperti itu, saya jadi lebih hati-hati waktu develop list pake data mockup, dan mastiin kasus-kasus tersebut sudah terhandle.
Di sini saya nyobain gimana tampilan kalau datanya lebih dari 1, kalau span count nya jadi 3, dan kalau title nya kepanjangan. Dari situ jadi tahu ternyata masih ada tampilan yang kurang sesuai, jadi bisa langsung saya benerin.
Attach Debugger to Process
Lagi ngetes fitur eh aplikasinya force close. Waktu dilihat di log nya, kayanya fix nya gampang deh, pengen mastiin solusinya kaya yang saya pikirin bukan yah? Daripada harus nunggu lama-lama buat run ulang (yang kalo aplikasi saya run butuh build selama 1 menit), mending saya attach debugger deh, terus coba evaluate expression buat mastiin solusinnya, baru deh kalo emang bener tinggal dimasukin ke real code terus build lagi.
Setiap aplikasi yang diclose ataupun terjadi force close, debugger pasti terdisconnect, maka dari itu saya attach debugger. Karena error null pointer exception, saya pastiin dulu data apa yang null, terus saya coba deh ngubah code biar data nya engga null, dan ternyata dugaan saya benar.
Contoh kasus yang saya berikan mungkin sangat sederhana, tetapi kalian bisa ngembangin sendiri metode debugging kalian sesuai dengan kasus real yang kalian dapat.
Terimakasih sudah membaca dan sampai jumpa di story selanjutnya!
