Panduan Praktis Implementasi Unit Testing di Model dan Controller Laravel

Pendahuluan

Bayangin lagi ngerjain fitur sederhana, tapi pas mau deploy malah dapet error aneh di modul yang kelihatannya nggak kesentuh sama sekali. Saya sering banget ngalamin ini, di mana perubahan kecil di logic model bikin fitur di controller jadi berantakan tanpa sadar. Akhirnya, nulis test bukan lagi soal pilihan, tapi cara biar kita bisa tidur nyenyak setelah push code.

Tips & Best Practices

Di banyak project, biasanya saya mulai dari bikin factory yang rapi supaya data testing nggak berantakan. Jangan pernah hardcode data di dalam file test, mending pakai model factory biar gampang di-scale. Selain itu, saya selalu biasain buat misahin logic berat dari controller ke service class, jadi controller-nya cuma nerima request dan balikin response, ini ngebantu banget pas mau nulis test-nya nanti. Terakhir, manfaatin trait RefreshDatabase biar tiap test punya lingkungan yang bersih, jadi nggak perlu pusing sama sampah data dari test sebelumnya.

Contoh Kode

Biasanya saya tes model buat mastiin relationship atau mutator jalan. Contohnya kayak gini:

public function test_user_has_many_posts() { $user = User::factory()->create(); $post = Post::factory()->create(['user_id' => $user->id]); $this->assertTrue($user->posts->contains($post)); }

Sementara buat controller, saya lebih suka tes flow-nya:

public function test_store_creates_new_post() { $response = $this->post('/posts', ['title' => 'Test', 'body' => 'Content']); $response->assertStatus(201); $this->assertDatabaseHas('posts', ['title' => 'Test']); }

Variasi Implementasi

Ada dua pendekatan yang sering saya bandingin. Pakai Feature Test emang lebih enak buat mastiin endpoint jalan bener, tapi kadang lemot kalau test suite-nya udah ribuan. Di sisi lain, Unit Test murni buat model jauh lebih cepet eksekusinya. Saran saya, fokusin Feature Test ke flow utama aplikasi, sementara Unit Test dipake buat logic bisnis yang kompleks di dalam model atau helper.

Kesalahan Umum

Pertama, banyak dari kita yang ngetes terlalu detail sampai ke internal framework, padahal yang penting logic kita yang jalan. Kedua, lupa mock external service (kayak Payment Gateway), ini sering bikin test gagal gara-gara internet atau API down. Ketiga, nulis test yang saling bergantung antar file, ini mimpi buruk pas mau debugging. Keempat, mengabaikan edge case kayak input null atau string kosong yang sering bikin aplikasi crash. Terakhir, ngerasa cukup cuma ngetes happy path aja, padahal error handling justru bagian yang paling rawan bug.

Ringkasan

Testing itu bukan beban tambahan, tapi semacam jaring pengaman yang bikin kita lebih pede pas mau refactor code besar-besaran. Jangan paksain bikin coverage 100% dari awal, mulai aja dari fitur yang paling krusial dulu. Pas nanti project-nya makin gede, kamu bakal ngerasa bersyukur banget pernah luangin waktu buat nulis test ini.