Testing Laravel: Latar Belakang

Pada artikel ini dan beberapa artikel kedepan, saya ingin berbagi cerita tentang pengalaman saya menggunakan metode Test-Driven Development (TDD), cara memulai, apa saja yang perlu di-test, dan studi kasus yang ringan. Mudah-mudahan dapat membantu teman-teman yang ingin menerapkan TDD dalam pekerjaannya.

Sebelum memulai membahas Testing Laravel, ijinkan saya menceritakan latar belakang mengapa “Testing itu Penting?”, menurut pengalaman saya selama beberapa tahun terakhir.

Problem yang dihadapi oleh Developer

Seorang developer (terutama freelancer) kadang mengalami perasaan “takut” saat diminta melakukan improvement pada aplikasi buatannya sendiri, terutama jika sudah berjalan di server production dan sedang digunakan oleh user. Misal kita diminta menambah fitur baru atau mengubah fitur yang sudah berjalan.

Kenapa kok takut, padahal aplikasi itu kan buatan kita sendiri? Satu alasan terlintas di pikiran adalah karena kita cenderung sudah lupa dengan “coding” kita sendiri. Apalagi jika bekerja sebagai freelancer, umumnya setelah selesai mengerjakan satu project, kita langsung mencari, mengambil pekerjaan/project lain, dan fokus pada project selanjutnya.

Bener nggak?

Contoh Kasus

Satu waktu kita menyelesaikan sebuah project aplikasi untuk sebuah perusahaan. Selanjutnya sistem itu digunakan sekaligus (tahap) pengujian oleh user/klien selama 1-2 bulan, untuk memastikan semua fitur berjalan sesuai dengan target dan tujuan. Setelah masa pengujian selesai dan semua fitur sudah Oke (mungkin setelah beberapa bugfix), aplikasi digunakan oleh perusahaan secara penuh. Selesai pekerjaan sampai di situ.

Enam bulan kemudian, perusahaan tersebut menghubungi kita lagi untuk meminta improvement di sistemnya. Setelah berdiskusi, ada beberapa fitur yang ingin ditambahkan ke sistem, dan ternyata ada beberapa fitur yang diubah karena adanya perubahan kebijakan perusahaan.

Apa yang harus kita lakukan untuk memenuhi permintaan tersebut, dengan catatan, sistem yang sudah ada sekarang tetap digunakan paralel dengan proses improvement?

Potensi “Bug setelah Improvement”

Menurut pengalaman, kondisi ini bisa membuat kita (terutama saya) takut untuk menambah/mengubah fitur pada aplikasi buatan sendiri, karena :

• Harus mengubah stuktur tabel yang saat ini sudah berjalan dengan aman.
• Ada potensi bug yang muncul akibat perubahan struktur database.
• Ada potensi bug yang muncul akibat penambahan/perubahan script fitur yang dilakukan.
• Kita sudah lupa dengan workflow yang diterapkan saat membuatnya, sementara project yang kita kerjakan setelahnya menggunakan workflow baru.
• Proses migrasi data yang sudah ada (existing) ke sistem yang baru (setelah ditambah fitur).

Dengan beberapa alasan tersebut, bisa jadi kita akan ragu untuk mengerjakan improvement yang diminta, karena memikirkan impact/akibatnya, misalkan :

• Komplain yang tidak terduga dari user beberapa minggu setelah improvement selesai.
  Misal ada laporan: “Mas kemarin yang ini perhitungannya bener, kok sekarang salah?”.
• Kadang waktu yang diperlukan untuk perbaikan impact bisa lebih banyak daripada waktu pengerjaan improvement.
  Misal: kita sudah perbaiki bug yang dilaporkan, tetapi perbaikan tadi menjadi bug lagi pada fitur lain, yang sebelumnya baik-baik saja, seterusnya sampai tidak ada laporan bug lagi.
• (Saat mengerjakan improvement) Fokus pekerjaan terbagi antara mengerjakan fitur baru dengan rasa takut komplain yang akan datang belakangan.

Bagi sebagian orang mungkin ini hal yang biasa, karena ini adalah “resiko” dari proses improvement sebuah sistem dan ini harus dipahami oleh user/klien (pengguna aplikasi). Tapi bagi saya pribadi, potensi impact ini lumayan mengganggu, karena kita harus tetap bertanggung jawab atas kelalaian kita sendiri pada saat pengerjaan improvement itu. Bayangkan waktu dan pikiran yang dihabiskan untuk perbaikannya, padahal di saat yang sama kita sedang mengerjakan project yang lain.

Apa lagi setelah bug diperbaiki, muncul bug lain lagi.

Mumet, kan? Mumet.

Tapi kan bagaimanapun kita mesti maju, tidak bisa bilang kepada klien bahwa kita takut memenuhi permintaan itu. Orang aplikasinya juga kita yang bikin. Ntar malu kita..

Nah? jadi curcol..

Oke, anggap saja improvement kita sanggupi dan sudah kita kerjakan.

SOLUSI tradisional untuk Potensi “Bug setelah Improvement”

Setelah pekerjaan improvement selesai, mestinya kita melakukan pengujian untuk memastikan aplikasi berjalan dengan baik tanpa ada bug, bukan?

Pengujian dilakukan oleh Developer

Bayangkan misal aplikasi ini memiliki 10 fitur utama, dan masing-masing fitur utama memiliki 4-5 sub-fitur, sehingga ditotal sekitar 50 fitur. Apakah setelah melakukan improvement tadi, kita menguji semua fitur secara manual?

Misal dengan cara :

• Buka browser dan Login
• Input form satu-satu
• Input form dengan kondisi input yang salah
• Cek hasil input form di aplikasi atau di database

Satu persatu fitur sampai dirasa cukup.

Jika aplikasi tidak terlalu besar, proses pengujian manual ini tidak masalah. Tapi untuk kasus ini, proses di atas kita lakukan setidaknya untuk 10 fitur utamanya. Atau hanya fitur-fitur lama yang berkaitan dengan fitur baru (yang dibuat setelah improvement).

Idealnya memang semua fitur harus diuji, tapi apakah seorang programmer akan “se-rajin” itu? Silakan jawab sendiri :D

Bayangkan, berapa banyak waktu yang kita habiskan untuk memastikan semua fitur berjalan lancar setelah improvement selesai? Kalau aplikasi tidak terlalu kompleks, mungkin 1 hari selesai pengujian. Tetapi jika aplikasi lumayan kompleks dengan fitur-fitur yang saling berhubungan satu sama lain? Mungkin perlu 2 hari, seminggu, atau “kalau rajin” bisa 2 minggu. Padahal pengerjaan improvement nya hanya 1 atau 2 hari saja sudah beres.

Membiarkan user komplain?

Alternatifnya jika kita tidak mau repot, kita biarkan user yang mencoba sendiri, ketika ada masalah biarkan melapor, kemudian bug diperbaiki. Begitu seterusnya sampai tidak ada laporan lagi.

Cara ini resikonya cukup besar, bisa membuat hubungan kita dengan klien menjadi renggang gara-gara keseringan adu argumen soal bug. Bisa membuat image kita jelek kurang bagus di mata klien. Dan menurut saya, cara kerja ini sangat tidak efektif dan menghabiskan waktu.

Ditambah lagi (jika) setelah improvement ini kita langsung ke project berikutnya, kondisi seperti ini berpotensi membuat kita dikejar deadline. Karena bisa jadi kita tidak fokus mana yang mau diprioritaskan di antara :

• Bugfix,
• Pikiran kekhawatiran bug berikutnya, dan
• Project yang sedang berjalan.

Jika Aplikasi punya “Automated Testing”?

Dengan contoh kasus di atas, saya pertimbangan untuk memulai belajar Automated Testing. Kenapa? Karena saya pikir, dengan aplikasi yang memiliki Automated Testing, kita (sebagai developernya) memiliki backup yang dapat membantu kita memastikan bahwa aplikasi ini sudah teruji secara otomatis dengan bantuan komputer.

Dibandingkan jika kita harus menguji sistem secara manual, dengan adanya Automated Testing (selanjutnya kita sebut testing) yang dipasang pada aplikasi buatan kita, ke 50 fitur tadi diuji oleh komputer dengan waktu yang cepat. Bayangkan betapa hematnya waktu kita ketika pengujian (misal) 50 Fitur cukup perlu waktu 30 detik.

Jadi jika ada bug yang disebabkan oleh improvement tadi? Testing segera memberitahu kita dengan cara menampilkan error yang terjadi. Baik karena script yang salah, atau struktur database yang ada tidak sesuai dengan script yang baru.

Yap, dalam waktu sekian detik, bug yang disebabkan oleh improvement tadi segera ketahuan. Walhasil, saat itu juga kita dapat segera memperbaikinya, tanpa menunggu laporan dari user yang bikin kita mumet kita di kemudian hari.

Kita akan membahas tentang Automated Testing pada artikel berikutnya.

Kesimpulan Latar Belakang “Kenapa Testing itu Penting?”

Oke, kita simpulkan materi latar belakang pentingnya testing dalam pengembangan sebuah sistem/aplikasi :

1. Sebagai backup kita jika ada improvement sistem di kemudian hari
2. Sebagai jaminan bahwa aplikasi yang berjalan sudah sesuai dengan spesifikasi yang diinginkan
3. Membantu mempercepat informasi bug akibat perubahan yang dilakukan
4. Membuat kerja, pikiran, dan hidup lebih tenang :D

Demikian ulasan tentang latar belakang mengapa saya mempertimbangkan untuk belajar Automated Testing. Saya berharap teman-teman merasa :
“Oh, iya, setuju, ternyata automated testing itu besar sekali manfaatnya.”

Mudah-mudahan artikel ini dapat menjadi referensi untuk memantapkan niat teman-teman yang ingin belajar dan membuat testing dalam membangun aplikasi. Pada artikel selanjutnya, kita akan membahas lebih lanjut tentang Automated Testing.

Terima kasih teman-teman sudah berkanan membaca.