Laravel’da test yazmak başlangıçta oldukça basit görünebilir. Birkaç test yazarsınız, php artisan test komutunu çalıştırır, yeşil çıktıları görür ve devam edersiniz. Ancak rahatsız edici gerçek şu ki: geçen testlerin çoğu, uygulamanızı korumaz.
Eğer testleriniz gerçek hataları yakalamıyorsa, bu sadece işe yaramaz olmakla kalmaz, aynı zamanda size yanlış bir güven duygusu verir.
Bu makalede, test paketinizin değerini gizlice kıran en yaygın Laravel test hatalarını, pratik örneklerle ve daha iyi yaklaşımlarla birlikte ele alacağız.
1. Davranış Yerine Uygulamayı Test Etmek
1. Davranış Yerine Uygulamayı Test Etmek
En büyük hatalardan biri, uygulamanızın gerçekten ne yaptığını doğrulamak yerine, kodunuzu yansıtan testler yazmaktır.
Kötü Örnek
Kötü Örnek
public function test_it_calls_service_method()
{
$service = Mockery::mock(UserService::class);
$service->shouldReceive('createUser')->once();
$controller = new UserController($service);
$controller->store(new Request([...]));
}
Bu test yalnızca bir metodun çağrıldığını kontrol eder. Ancak aşağıdakileri doğrulamaz:
- ne yaratıldığı
- verilerin doğru olup olmadığı
- gerçekten bir şeyin çalışıp çalışmadığı
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
public function test_user_is_created()
{
$response = $this->post('/users', [
'name' => 'John Doe',
'email' => '[email protected]',
]);
$response->assertStatus(201);
$this->assertDatabaseHas('users', [
'email' => '[email protected]',
]);
}
Önemli olan gözlemlenebilir davranış üzerine odaklanmaktır, içsel çağrılar üzerinde değil.
2. Mockları Aşırı Kullanmak
2. Mockları Aşırı Kullanmak
Mocklar güçlüdür — ancak aşırı kullanımı, dayanaksız ve anlamsız testler ile sonuçlanır.
Problem
Problem
Problem
Problem
Her şeyin mocklanması durumunda:
- gerçek entegrasyonu test etmiyorsunuz
- sistem bozulduğunda bile testler geçiyor
Http::fake();
$response = $this->get('/weather');
$response->assertStatus(200);
Bu, aşağıdakiler hakkında hiçbir şey söylemez:
- yanıt yapısı
- veri doğruluğu
- kısıt durumları
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Sadece gerekli olanları (dış hizmetleri) mocklayın ve anlamlı çıktıları doğrulayın:
Http::fake([
'*' => Http::response(['temp' => 25], 200),
]);
$response = $this->get('/weather');
$response->assertJson([
'temperature' => 25,
]);
Şu kuralı aklınızda bulundurun:
Boundary’leri mocklayın, kendi mantığınızı değil.
3. Her Zaman Geçen Testler Yazmak
3. Her Zaman Geçen Testler Yazmak
Bazı testler, kod bozuk olsa bile başarısız olamayacak şekilde yazılmıştır.
Örnek
Örnek
Örnek
public function test_response_is_ok()
{
$response = $this->get('/users');
$response->assertStatus(200);
}
Bu test, aşağıdaki durumlarda bile geçer:
- yanıt boşsa
- yanlış veri dönerse
- iş mantığı bozuksa
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
$response->assertJsonStructure([
'data' => [
'*'=> ['id', 'name', 'email'],
]
]);
Daha da iyisi:
$this->assertDatabaseCount('users', 3);
Kendinize sorun:
“Bu test hangi hatayı yakalayacak?”
Cevap “hiçbiri” ise, yeniden yazmalısınız.
4. Kısıt Durumları Görmezden Gelmek
4. Kısıt Durumları Görmezden Gelmek
Çoğu hata “mutlu yol”da ortaya çıkmaz. Kenar durumlarında meydana gelir.
Yaygın Hata
Yaygın Hata
Yalnızca geçerli girdi test etmek:
$this->post('/users', [
'email' => '[email protected]',
]);
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Geçersiz senaryoları test edin:
$this->post('/users', [
'email' => 'not-an-email',
])->assertSessionHasErrors('email');
Ayrıca test edin:
- eksik alanlar
- tekrar eden değerler
- beklenmeyen girdiler
İyi testler, uygulamanızı kırmaya çalışır.
5. Birim Testlerinde Aşırı Test Yapmak
5. Birim Testlerinde Aşırı Test Yapmak
Birim testleri hızlı ve odaklanmış olmalıdır. Ancak birçok geliştirici bunları mini entegrasyon testlerine dönüştürüyor.
Örnek
Örnek
Örnek
public function test_order_creation()
{
$order = OrderService::create([...]);
$this->assertDatabaseHas('orders', [...]);
}
Bu, iş mantığını ve veritabanı katmanını karıştırır.
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Sorumlulukları ayırın:
Birim testi (sadece mantık):
public function test_total_price_is_calculated_correctly()
{
$total = OrderCalculator::calculate([100, 200]);
$this->assertEquals(300, $total);
}
Özellik testi (tam akış):
$this->post('/orders', [...]);
$this->assertDatabaseHas('orders', [...]);
Test katmanlarınızın temiz olmasını sağlayın.
6. Fabrikaları Doğru Kullanma
6. Fabrikaları Doğru Kullanma
Laravel fabrikaları güçlüdür, ancak birçok geliştirici bunları yanlış kullanıyor.
Problem
Problem
Problem
Problem
Her şeyi hardcoding yapmak:
User::create([
'name' => 'Test',
'email' => '[email protected]',
]);
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
$user = User::factory()->create();
Daha da iyisi:
$user = User::factory()->state([
'email_verified_at' => now(),
])->create();
Faydaları:
- daha az boilerplate
- daha esnek testler
- daha kolay bakım
7. Test Verilerini Temizlememek
7. Test Verilerini Temizlememek
Kirli test verileri güvenilmez testlerle sonuçlanabilir.
Problem
Problem
Problem
Problem
Testler önceki duruma bağımlıdır.
Çözüm
Çözüm
Kullanın:
use Illuminate\Foundation\Testing\RefreshDatabase;
Bu, her test için:
- temiz bir veritabanı sağlar
- tutarlı sonuçlar sunar
Güvenilmez testler, test paketinizde güvensizlik yaratır.
8. Çok Karmaşık Testler Yazmak
8. Çok Karmaşık Testler Yazmak
Testiniz okunması zorsa, muhtemelen çok fazla şey yapıyordur.
Örnek
Örnek
Örnek
public function test_everything()
{
// 50 satır kurulum
// 10 doğrulama
}
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Daha İyi Yaklaşım
Parçalara ayırın:
public function test_user_can_register() {}
public function test_email_must_be_unique() {}
public function test_password_is_required() {}
Her test bir soruyu yanıtlamalıdır.
9. Performansı Görmezden Gelmek
9. Performansı Görmezden Gelmek
Yavaş testler genellikle atlanır — ve atlanan testler işe yaramaz testlerdir.
Problem
Problem
Problem
Problem
- çok fazla DB çağrısı
- gereksiz kurulum
- ağır fixture’lar
İpuçları
İpuçları
- hafıza içi veritabanı kullanın (SQLite)
- gereksiz tohumlamadan kaçının
- birim testlerini hızlı tutun
Hızlı testler = gerçekten çalıştırdığınız testler.
10. Gerçek Kullanıcı Akışlarını Test Etmemek
10. Gerçek Kullanıcı Akışlarını Test Etmemek
Izole parçaları test etmek yeterli değil.
Problem
Problem
Problem
Problem
Hizmetlerinizi ve denetleyicilerinizi ayrı ayrı test edersiniz, ancak asla tam akışı test etmezsiniz.
Örnek
Örnek
Örnek
public function test_user_can_register_and_login()
{
$this->post('/register', [
'email' => '[email protected]',
'password' => 'password',
]);
$this->post('/login', [
'email' => '[email protected]',
'password' => 'password',
])->assertRedirect('/dashboard');
}
Asıl önemli olan:
Kullanıcı işlemi tamamlayabiliyor mu?
Son Düşünceler
Son Düşünceler
Laravel test yazmayı kolaylaştırır — ancak yararlı testler yazmak farklı bir beceridir.
Eğer testleriniz:
- sadece durum kodlarını kontrol ediyorsa
- her şeyi mocklıyorsa
- uygulamanızı yansıtıyorsa
…o zaman uygulamanızı korumazlar.
Bunun yerine, şunlara odaklanın:
- gerçek davranış
- anlamlı doğrulamalar
- kenar durumları
- gerçekçi kullanıcı akışları
Küçük bir yüksek kaliteli test seti, zayıf bir büyük test setinden çok daha değerlidir.
Hızlı Kontrol Listesi
Hızlı Kontrol Listesi
Bir testi eklemeden önce sorun:
- Bu test önemli bir şey bozulduğunda başarısız olur mu?
- Davranışı mı, uygulamayı mı test ediyorum?
- Gerçek bir hatayı yakalayacak mı?
- Bu test basit ve okunabilir mi?
Cevap “hayır” ise, onu geliştirme zamanı.
İyi yazılmış testler yalnızca kapsama değil, aynı zamanda güvene de dayanır. Ve güven, gerçekten önemli olan testlerden gelir.
Kaynak: Orijinal Makale
- 1. Davranış Yerine Uygulamayı Test Etmek
- 2. Mockları Aşırı Kullanmak
- 3. Her Zaman Geçen Testler Yazmak
- 4. Kısıt Durumları Görmezden Gelmek
- 5. Birim Testlerinde Aşırı Test Yapmak
- 6. Fabrikaları Doğru Kullanma
- 7. Test Verilerini Temizlememek
- 8. Çok Karmaşık Testler Yazmak
- 9. Performansı Görmezden Gelmek
- 10. Gerçek Kullanıcı Akışlarını Test Etmemek
- Son Düşünceler
- Hızlı Kontrol Listesi


