Unit test yazmaya başladığım ilk dönemde, "test yazıyorum" diye kendimi güvende hissediyordum, ama sonradan bu testlerin çoğunun gerçek değer katmadığını fark ettim. En sık düştüğüm tuzakları paylaşmak istiyorum.
Implementasyonu Test Etmek, Davranışı Değil
Bir metodun içindeki her adımı ayrı ayrı doğrulayan testler yazmıştım; bu testler, metodun iç yapısını değiştirdiğimde (davranış aynı kalsa bile) kırılıyordu. Artık testlerimi "bu girdi verildiğinde şu çıktı/durum oluşmalı" mantığıyla, davranışa odaklı yazıyorum.
Aşırı Mock Kullanmak
Her bağımlılığı mock'lamaya çalışmak, testi gerçek koddan çok mock kurulumuna dönüştürüyor. Sadece dış dünyaya çıkan bağımlılıkları (veritabanı, dış API, dosya sistemi) mock'luyorum; saf mantık içeren sınıfları gerçek nesnelerle test ediyorum.
Tek Testte Birden Fazla Şeyi Doğrulamak
Bir testte hem "sipariş oluşturuldu mu", hem "e-posta gönderildi mi", hem "stok azaldı mı" gibi birden fazla şeyi kontrol etmek, test başarısız olduğunda hangi kısmın bozulduğunu anlamayı zorlaştırıyor. Her testin tek bir net iddiası (assertion) olmasını önemsiyorum.
[Fact]
public void CreateOrder_Should_Set_Status_To_Pending()
{
var order = Order.Create(customerId, items);
Assert.Equal(OrderStatus.Pending, order.Status);
}Test İsimlerini Anlamsız Bırakmak
Test1(), Test2() gibi isimler, bir test kırıldığında ne test ettiğini anlamayı zorlaştırıyor. MethodName_Scenario_ExpectedResult formatını kullanmak, test raporunu okurken bile neyin yanlış gittiğini anlamamı sağlıyor.
Sonuç
Test yazmak, sadece "kod kapsama oranını yükseltmek" için yapılan mekanik bir görev değil. İyi yazılmış testler, kodun davranışını belgeleyen, gelecekteki değişikliklerde güven veren bir güvenlik ağı olmalı.