Unit Testler ve Mimari Testlerle Kod Kalitesini Korumak
Bir kuralın ihlal edilip edilmediğini insan hafızasına değil teste bırakıyorum.
Mert Celal Yılmaz · Full Stack Developer · Güncellendi:
Bir kodun çalıştığını görmek başka bir şey, altı ay sonra biri onu değiştirdiğinde hâlâ doğru çalıştığından emin olmak başka bir şey. Unit testler tam olarak bunun için var: bir handler'ın ya da bir metodun belirli girdilerde beklenen çıktıyı verdiğini, bağımlılıkları mock'layarak izole şekilde doğruluyorsun. Mimari testler ise kodun davranışını değil, katmanlar arasındaki bağımlılık kurallarını test ediyor; Domain katmanının Infrastructure'a referans vermemesi gibi bir kural, elle yapılan code review'a değil otomatik bir teste bırakılıyor.
Genel iş akışımda otomatik test süreçlerine öncelik veriyorum; yeni bir feature'ı test yazmadan bitmiş saymıyorum. Bir apartman yönetim sisteminde iki kişilik bir ekipte çalışırken code review sürecini biz kurduk ve kod kalitesi standartlarını da bu süreçte netleştirdik. İki kişilik bir ekipte code review'u ciddiye almak büyük ekiplerden daha kritik, çünkü gözden kaçanı yakalayacak üçüncü bir göz yok.
Mimari testler bu noktada ayrı bir güvence katmanı oluyor. Katman ihlalini bir insanın code review'da fark etmesini beklemek yerine, build sırasında otomatik olarak kırılan bir test olarak görüyorsun; kural ihlal edildiği an anlıyorsun, iki hafta sonra beş değişikliğe karışmış hâlde değil. Bu tür testler yazmak başta ekstra iş gibi görünüyor ama sonradan bedava sigorta gibi çalışıyor.
Mimari testler pratikte NetArchTest gibi bir kütüphaneyle assembly'leri reflection üzerinden tarayarak çalışıyor — kural cümlesi ('Domain katmanı Infrastructure'a bağımlı olmasın' gibi) kodun using ifadelerine değil, derlenmiş IL'deki gerçek tip referanslarına bakılarak değerlendiriliyor. Apartman yönetim sisteminde bu yaklaşım sayesinde bir metodun parametre tipinde ya da private bir alanda saklı kalan dolaylı bir bağımlılığı bile yakalayabiliyoruz, halbuki dosyayı gözle okurken böyle bir referans kolayca gözden kaçabilir.
Mimari testleri akla gelen her katman kuralı için yazmak küçük projelerde ayrı bir bakım yüküne dönüşebiliyor — kural sayısı arttıkça test takımının kendisi kırılganlaşıyor ve her meşru istisna için ayrı bir muafiyet eklemek gerekiyor. İki kişilik ekipte bu dengeyi genelde şöyle kurduk: mimari testler sadece ihlali gerçekten pahalıya patlayan birkaç kuralı (domain'in altyapıya bağımlı olmaması gibi) koruyor, daha ince stil ve tasarım kararlarını hâlâ karşılıklı code review'da konuşuyoruz.