Nafies Luthfi

Life will always feel wonderful if we always think positively.

Testing Laravel: Apa Saja yang Perlu Dibuatkan Test?

Bismillahirrahmanirrahim.

Jika kita baru mulai menerapkan Test-Driven Development dalam mengerjakan project, mungkin awalnya kita bingung, bagian mana saja yang perlu dibuatkan testing? Oke lah, yang jelas fitur CRUD, lalu pada artikel yang lalu kita sudah tahu tentang Model Behaviour, kita juga perlu membuat unit testing untuk itu. Lalu apa lagi yang perlu kita buat test selain itu? Baik kita bahas sama-sama bagian mana saja (yang menurut saya) harus kita buatkan testing scriptnya.

Di sini juga akan kita bahas pembagian level class Test Case (class testing script) dari yang saya pahami dan terapkan secara umum. Apakah sebuah Test Case masuk ke level Feature Test atau ke level Unit Test.

Level Feature Test

Pada bagian ini, class Test Case ditempatkan pada direktori tests/Feature di project Laravel. Test Case yang masuk ke dalam Feature test adalah fitur-fitur utama dalam aplikasi, seperti entry data, edit data, hapus data dan API endpoint.

1. Fitur CRUD

Pertama yang utama adalah fitur-fitur yang berinteraksi dengan perubahan record pada database. Misalnya fitur entry artikel, edit artikel, hapus artikel, pengelolaan kategori artikel, dan fitur-fitur lain. Dalam Test Case ini kita definisikan fitur sesuai dengan spesifikasi kita.

Misalnya, saat “create” record, field-fieldnya apa saja, mana yang wajib diisi, mana yang nullable. Kemudian saat “update” record, mana yang wajib mana yang nullable, dan saat “delete” record, kondisi apa saya yang harus terpenuhi sehingga user boleh menghapus record tersebut dari database.

Contoh class Test Case Fitur CRUD (silakan klik link untuk melihat source-code nya) :

  1. Fitur Pengelolaan Pembayaran
  2. Fitur Pengelolaan Customer dan Vendor
  3. Fitur Pengelolaan Produk
  4. Fitur Input Transaksi Penjualan
  5. Fitur Edit Profil User
2. API Endpoints

Jika pada sistem kita terdapat web service atau API, sebaiknya seluruh Endpoint API-nya dibuatkan test, untuk memastikan parameter yang dikirimkan ke endpoint, serta respons yang dihasilkan dari endpoint sudah sesuai dengan spesifikasi yang diinginkan.

Mirip seperti Fitur CRUD pada point nomor 1 di atas, jika pada API Endpoint terdapat interaksi yang mengubah record pada database, sebaiknya pada Test Case untuk API Endpoint dibuatkan sesuai spesifikasi yang diinginkan.

Contoh class Test Case Fitur API Endpoint :

  1. Fitur API Event Kalender
  2. Fitur Pencarian Produk dengan AJAX

Level Unit Test

Pada bagian ini, class-class Test Case kita akan masuk dalam direktori tests/Unit pada project Laravel. Pertimbangannya adalah, karena kita menguji bagian-bagian kecil dari sistem/aplikasi kita. Misalnya pengujian terhadap method-method khusus pada class Model (Model Behaviour), hak akses/otorisasi user terhadap sebuah model (record), pengujian helper functions, dan pengujian untuk class-class PHP yang dibuat untuk membantu jalannya sistem.

1. Model Behaviour

Seperti yang sempat kita bahas pada artikel terdahulu, model behaviour adalah method-method khusus yang kita tambahkan pada class Model Laravel. Yang bertujuan untuk refactor method di controller, atau membuat source-code kita lebih “readable” karena mirip seperti pendelegasian tugas dan definisi “jobdeks” dari sebuah model.

Termasuk di dalamnya pendefinisian relasi antar model (antar tabel) dan attribute model yang didefinisikan melalui Eloquent Accessor.

Contoh class Test Case Model Behaviour :

  1. Test Case ProjectTest, untuk relationship dan method class model Project.
  2. Test Case SubscriptionTest, untuk relationship dan method class model Subscription (langganan).
  3. Test Method a_job_has_progress_attribute, untuk menguji Eloquent Accessor atribute “progress” pada model Job. Di mana nilai atribute progress dihitung berdasarkan rata-rata progress task pada job tersebut.
  4. Test Case ProductTest, untuk class model Product.
  5. Test Case PersonRelationTest, untuk menguji hubungan antar (model) User para project Aplikasi Silsilah.
2. Model Policy

Sedikit pengantar tentang Model Policy Object pada Laravel, Model policy adalah salah satu fitur Laravel yang (menurut saya) sangat bermanfaat untuk kebutuhan pengendalian akses user dalam sistem. Fitur ini benar-benar menghemat penggunaan fungsi “if”, baik di view maupun di controller.

Contoh kasusnya dalam sistem, misal halaman detail sebuah “project” dapat diakses oleh seluruh user, tetapi “nilai project” hanya dapat dilihat oleh user dengan role Project Manager dan Admin. Atau misal detail sebuah “job” dalam “project” hanya dapat di-edit oleh project manager dan pekerja yang ditugaskan ke dalam project itu, petugas dengan job lain tidak boleh meng-edit. Nah, model policy sangat bermanfaat untuk keperluan seperti ini.

Contoh class Test Case Model Policy :

  1. Test Case UserPolicyTest, untuk menguji class UserPolicy.
  2. Test Case CustomerPolicyTest, untuk menguji class CustomerPolicy.
4. Service Class

Service class adalah class-class PHP yang kita buat pada project kita yang digunakan untuk membantu jalannya sistem. Misal aplikasi kita memiliki fitur Shopping Cart, kemudian kita membuat sebuah class PHP bernama “Cart” dengan berbagai method dan property didalamnya agar fitur Shopping Cart yang kita inginkan dapat berjalan sesuai spesifikasi.

Untuk memastikan class “Cart” (service class) tadi berjalan sesuai dengan target, maka kita membuatkan test case untuk class tersebut.

Contoh class Test Case Service Class :

  1. Test Case CartCollectionTest, untuk menguji service class CartCollection. Service class ini digunakan pada fitur Shopping Cart atau Draft Transaksi untuk project Grosir Obat.
  2. Test Case InvoiceDraftCollectionTest, untuk menguji service class InvoiceDraftCollection. Service class ini digunakan pada fitur Draft Invoice (Entry Invoice) untuk project Free PMO.

Contoh lain adalah ketika kita membuat sebuah service class untuk mengintegrasikan sistem kita dengan API dari luar, misal Twitter, Instagram, atau Raja Ongkir. Service class ini juga perlu kita buatkan Test Case untuk memastikan komunikasi dengan API dari pihak luar tersebut berjalan sesuai dengan spesifikasi kita. Tetapi kebetulan saya belum ada contoh source-code untuk yang ini.

6. Number Generators

Kalau kita pernah membuat sebuah fitur penomoran atau kode otomatis untuk sistem kita, misal saat input invoice kemudian secara otomatis sistem memberi nomor urut invoice tersebut dengan pola tertentu, maka semestinya penomoran otomatis tersebut kita buatkan testing juga.

Misal sistem membuat penomoran otomatis (number generator) berdasarkan pola berikut: INV-aabbxxx di mana :

  • aa adalah tahun 2 digit
  • bb adalah bulan 2 digit
  • xxx adalah nomor urut invoice pada bulan tersebut

Maka seharusnya kita membuat testing untuk memastikan aplikasi kita meng-generate nomor urut yang benar setiap invoice dibuat.

Contoh sederhana testing script untuk menguji penomoran otomatis invoice seperti ini : it_generates_its_own_number. Test method ini pada dasarnya digunakan untuk menguji model behaviour pada model Invoice, tetapi contoh penggunaanya ada pada model factory invoice-nya.

Hmm.. terlihat agak repot ya. Kebetulan perihal “testing number generator” ini saya baru dapat ilmunya sekitar 2 bulan yang lalu, bahwa fitur-fitur yang menggunakan number generator itu (seharusnya) dibuatkan testing scriptnya. Saat artikel ini ditulis, belum ada contoh lain yang bisa saya sampaikan. Asumsi saya pribadi, testing number generator ini harus dibuatkan class Test Case class sendiri. Untuk memastikan semua kemungkinan/kondisi dapat diakomodir oleh testing scriptnya.

Insyaallah bagian ini akan saya update jika sudah ada contoh untuk testing number generator.

Test Case Tambahan (Optional)

Item-item yang sudah kita bahas di atas (menurut saya) adalah item-item yang harus dibuatkan test (prioritas utama), karena posisinya sangat vital pada sistem/aplikasi. Ada beberapa item lagi yang biasanya saya buatkan test case, sebagai pendukung.

1. Helper Function

Ketika kita membuat beberapa function helper, entah untuk mempersingkat script, atau agar beberapa baris script dapat “reusable” dalam source-code kita (prinsip DRY), ada baiknya function-function helper tersebut kita buatkan testing script juga. Sekedar memastikan bahwa function tersebut bekerja dengan baik pada versi Laravel/versi PHP yang kita gunakan sekarang.

Salah satu contoh function helper yang dibuatkan test case :

  1. Test Case AppLogoImageTest, untuk menguji function helper appLogoImage().

Sementara baru satu contoh itu, mudah-mudahan jika nanti ada contoh lain, bagian ini bisa saya update.

2. Model Factory

Item pendukung lainnya yang bisa dibuatkan Test Case adalah Model Factory. Biasanya testing diperlukan untuk model factory yang memiliki beberapa state atau defineAs (seperti contoh model factory ini).

Kita membuat testing untuk model factory untuk memastikan record yang di-generate oleh model factory sesuai dengan kebutuhan (umumnya untuk keperluan automated testing).

Kesimpulan

Baik, dengan pembahasan diatas, kita tarik beberapa kesimpulan tentang “Apa saja yang perlu dibuatkan test pada project Laravel?”.

  1. Fitur utama yang harus dibuatkan test adalah fitur CRUD, yaitu saat fitur tersebut berinteraksi dengan perubahan record pada database.
  2. **Feature Test Case class dibuat terlebih dahulu saat kita bekerja dengan metode TDD.
  3. Unit Test Case class dibuat sebagai pendukung bagian-bagian kecil dari sebuah fitur (yang diuji dengan Feature Test).

Hal-hal yang kita bahas di atas merupakan pendapat saya pribadi, bisa jadi tidak sesuai dengan pendapat teman-teman sekalian, dan bisa jadi akan berubah menyesuaikan kebutuhan di masa datang.

Jika ada masukan pendapat dari teman-teman pembaca, saya akan sangat berterima kasih sekali. Setidaknya harapan saya, mudah-mudahan pembahasan kali ini dapat menjadi referensi ketika kita jika masih ada pertanyaan :

“Apa saja/bagiam mana yang harus dibuatkan test dalam project Laravel saya?”

Terima kasih atas waktu teman-teman sudah berkenan membaca. :)