Nafies Luthfi

Life will always feel wonderful if we always think positively.

Testing Laravel: Tentang TDD (Test-Driven Development)

Sebagaimana sempat disinggung pada artikel sebelumnya , bahwa dengan menerapkan Automated Testing pada sistem/aplikasi yang kita buat, kita jadi kerja dua kali, yaitu :

  • Menulis kode untuk membangun aplikasi dan
  • Menulis kode untuk membuat kode pengujian setiap fitur yang ada pada sistem.

Jika testing script dibuat setelah sistem selesai, tentunya lumayan menyita waktu. Padahal biasanya User menginginkan sistem segera lauhcing dan mulai digunakan. Ditambah lagi developer biasanya sudah males ngutak-ngutik sistem yang sudah jadi (apalagi fiturnya banyak). Akhirnya batal bikin testing. :)

Metode paling efektif untuk menerapkan Testing Automation adalah Test-Driven Development (TDD). Menerjemahkan secara bebas pengertian dari Wikipedia :

Test-Driven Development adalah suatu metode pembangunan aplikasi dengan terlebih dahulu menulis “kode pengujian” sebelum menulis kode aplikasinya, sehingga testing memandu developer dalam proses development aplikasi tersebut.

Konsepnya seperti ini:

TDD Cycle

Sumber gambar : Test-Driven Development

Konsep Penerapan TDD

Misalkan kita ingin membuat sebuah fitur dengan TDD, metodenya seperti ini :

  1. Buat Kode Pengujian (Add Test).
  2. Jalankan test, hasilnya pasti fail (Watch Test Fail).
  3. Tulis Kode Fitur Sistem (Write Code).
  4. Jalankan test (Run Tests) hingga testing passed.
  5. Refactor Kode Fitur Sistem (Refactor).

Penerapan dari metode di atas, langkah aktual yang dikerjakan kurang lebih begini :

  1. Buat Kode Pengujian artinya kita membuat testing script (pada software testing) sesuai spesifikasi fitur yang diinginkan.
  2. Jalankan Test artinya kita menjalankan software testing untuk melihat testing fail (gagal) dengan pesan error-nya.
  3. Tulis Kode Fitur Sistem artinya kita mulai ngoding atau menulis script di aplikasi/sistem yang ingin dibuat. Script yang ditulis ini adalah script untuk memperbaiki error yang ditunjukkan oleh software testing.
  4. Jalankan Test lagi, ketemu pesan error yang berbeda (masih fail).
  5. Tulis script lagi untuk “memperbaiki” error-nya.
  6. Jalankan Test lagi hingga mendapatkan pesan error yang berbeda lagi (masih fail).
  7. Ulangi terus langkah “Tulis Kode”, “Jalankan Test”, “Tulis Kode”, “Jalankan Test” hingga mendapatkan testing passed (lulus).
  8. Ketika testing sudah passed, kita bebas refactor (mengutak-utik) kode/script pada aplikasi. Selama hasil testing-nya tetap passed artinya fitur tersebut tetap bekerja sebagaimana mestinya (sesuai spesifikasi).

Selesai sampai di situ untuk penerapan TDD dalam pembangunan satu fitur. Bagaimana untuk fitur berikutnya? Ya, sama seperti langkah di atas, kita buat testing, jalankan testing, perbaiki error pada testing, jalankan testing lagi, perbaiki lagi, dan seterusnya…

Jadi dalam TDD, testing “memandu” kita dalam membangun fitur yang kita inginkan. Jika seluruh spesifikasi fitur itu sudah dituangkan dalam script testing, maka kita akan “dipaksa” untuk ngoding sampai target (spesifikasi) kita terpenuhi, yang ditandai dengan testing-nya passed atau lulus.

Merasa repot dengan metode ini? Ya, saat awal mencoba memang agak repot, karena kita belum terbiasa. Saya sendiri awalnya merasa testing ini menghabiskan banyak waktu, tapi karena “merasa perlu” ya jalan terus. Lama-kelamaan terbiasa dan lancar.

Jika kita menerapkan metode/langkah tersebut sejak awal development hingga selesai, maka hasil yang kita dapatkan adalah sebuah “aplikasi yang handal”. “Wow, pede banget? Ya donk..” kita menyelesaikan sebuah aplikasi/sistem yang berjalan sesuai keinginan (spesifikasi) dan itu dijamin dengan testing automation, teruji oleh komputer tanpa perlu pengujian manual oleh manusia.

TDD Mempercepat Pembangunan Aplikasi?

Pada artikel sebelumnya , saya menyebutkan bahwa metode TDD dapat mempercepat kerja kita dalam membangun sebuah aplikasi. Yap, ingin menegaskan kembali, pada penerapan TDD ini, dengan adanya testing yang “memandu”, kita tinggal ngoding untuk memperbaiki error yang tampil di software testing saja, sampai testing-nya passed. Selanjutnya kita bisa refactor script aplikasinya, atau langsung melanjutkan membangun fitur berikutnya dengan metode yang sama, begitu seterusnya.

Bahkan kadang kita “tidak mesti” membuka browser (aplikasi) untuk memastikan apakah coding yang kita kerjakan sudah “jalan” atau belum, karena sudah “yakin” dengan testing yang passed. Kita buka browser pada saat ingin memperbaiki tampilan atau tata letak nya saja.

Memangkas aktifitas yang “agak” menyita waktu

Jadi apa saja sih pekerjaan yang dipangkas dengan metode TDD ini? Kita memangkas aktifitas-aktifitas yang sedikit menyita waktu. Menurut pengalaman saya, yang agak lumayan menyita waktu adalah hal-hal berikut :

  1. Setelah ngoding beberapa baris, kita buka browser untuk refresh halaman, atau submit form, lalu ngoding lagi, buka browser lagi, refresh, dan seterusnya.
  2. Kita membuka browser untuk simulasi mengisi form lebih dari 5 item dan submit formulir.
  3. Setelah selesai ngoding satu fitur, kita menguji “proses yang bertahap” di dalam sistem, misal :
    • Setelah mengisi keranjang belanja kita, checkout mengisi data diri (sebagai Customer).
    • Sebagai Reseller, setelah mengisi keranjang belanja kita, checkout mengisi data pengiriman.
  4. Simulasi fitur-fitur lain yang berhubungan dengan fitur yang barusan selesai dibuat.

Jadi dengan adanya testing untuk masing-masing fitur itu, kita tidak perlu mengetes lagi secara manual. Yang penting testing sudah dibuat mengikuti spesifikasi yang diinginkan dan testing-nya passed.

Nah kesimpulannya, kenapa metode TDD dapat mempercepat kerja kita dalam membangun sebuah aplikasi? Karena simulasi-simulasi yang dilakukan secara manual dapat diminimalisir dengan adanya testing yang sudah passed. Sudah itu aja jawabannya. :)

Memudahkan modifikasi fitur

Bagaimana jika ditengah proses developement atau saat sistem sudah hampir selesai, kita diminta modifikasi sebuah fitur karena User “baru kepikiran”, nah lho, ini sering banget kejadian. Oke, dengan adanya automated testing, kita tinggal modifikasi testing script fitur sesuai yang diminta oleh User tadi, lalu jalankan testing (pasti ketemu error), perbaiki error-nya, testing lagi sampai ketemu testing passed untuk fitur itu, maka modifikasi fitur selesai.

Apakah setelah selesai modifikasi fitur tadi pekerjaan selesai? Belum! Kita mesti uji juga apakah fitur yang barusan diubah tadi tidak “merusak” atau menjadi bug fitur lainnya (biasanya karena kita modifikasi tabel di database). Jika memang fitur itu menjadi bug untuk fitur lain, maka testing akan segera memberitahu kita, sehingga dapat segera diperbaiki (menjadikan seluruh testing menjadi passed).

Kesimpulan TDD

Dengan menerapkan metode Test-Driven Development, beberapa manfaat yang didapatkan oleh developer:

  1. Developer dipandu oleh testing dalam proses development.
  2. Semua target spesifikasi harus dituangkan dalam script testing agar mendapatkan fitur yang sesuai keinginan.
  3. TDD dapat mempercepat kerja karena meminimalisir simulasi manual oleh manusia.
  4. Modifikasi sebuah fitur dapat dilakukan “dengan tenang” karena ada Automated Testing yang mem-backup kita.
  5. Menambah percaya diri developer karena dapat membangun aplikasi yang handal teruji.

Semoga dengan membaca artikel ini teman-teman developer lebih mantap untuk memulai metode TDD dalam bekerja. Insyaallah pada artikel berikutnya kita mulai masuk ke praktek Testing Laravel, yaitu setup testing laravel yang biasa saya terapkan saat mulai project, dan memulai membuat testing script sebuah fitur.

Terima kasih atas waktunya.