Cevap.

Karmaşık uygulamaların iş mantığının otomatik test edilmesi, ilk doğrulayıcıları kontrol etmek için kullanılan ilk betiklerden modern mikro hizmet testlerine kadar uzun bir tarihe sahiptir. Mimariler (monolit, SOA, mikro ve makro hizmetler) karmaşıklaştıkça, bir mimari katmandaki değişikliklerin genellikle diğer katmanlardaki testleri bozması gibi bir sorun ortaya çıktı.

Sorun, uygulamanın katmanları arasındaki etkileşimin yeniden düzenlenmesine karşı dayanıklı testler yazma gerekliliğidir: sözleşmelerin, veri yapıların ve iş süreçlerinin değişimi. Genellikle testler, uygulamanın uygulanabilir ayrıntılarına sıkı sıkıya bağlıdır, bu da onları "kırılgan" ve zor bakım yapılabilir hale getirir.

Çözüm, giriş/çıkış verilerine odaklanarak "kara kutu" prensibine göre testler inşa etmek, sistemdeki varlıklara erişim için soyutlama katmanları kullanmak (örneğin, mimarideki Servis Katmanı ve Alan Katmanı). İş mantığını altyapı ayrıntılarından ayırmak ve dış bağımlılıklar için moke/stub'lar kullanmak, testlerin izolasyonunu ve istikrarını sağlamak gerekir.

Anahtar özellikler:

Sözleşmelerin test edilmesine vurgu: iş invariyanlarını içsel uygulamalardan bağımsız olarak kontrol etme.
Mantık erişimi için soyutlama katmanlarının kullanımı (örneğin, Uygulama Servisi → Alan Servisi → Depo).
Test ortamının yeniden üretilebilirliği ve izolasyonu için mvp/mocks/stubs uygulaması.

Kandırıcı Sorular.

UI katmanı üzerinden iş mantığını test etmek ile API/Domain Katmanı üzerinden test etmek arasındaki fark nedir?

UI testleri genellikle değişikliklere karşı daha az dayanıklıdır çünkü yüzeysel değişlikler testlerin başarısız olmasına yol açar. API veya Domain Katmanı üzerinden yapılan testler, ön yüzle daha az bağımlıdır ve iş kurallarının test edilmesini daha iyi izole eder.

İş mantığının test edilmesi için tüm bağımlılıkları.Mocklamak gerekli midir?

Hayır! Test ortamında uygulanabilir olan şeyleri moke etmemek gerekir (örneğin, veritabanı yerine hafif bir bellek). Moke, maliyetli veya karmaşık dış bağımlılıklar için gereklidir. Tam moke yapma, gerçek senaryoları yansıtmayan "hayali" testlere yol açabilir.

İş mantığı için yalnızca olumlu senaryoları test etmek yeterli midir?

Hayır! Tüm köşe durumlarını ve olumsuz senaryoları kapsamak önemlidir, aksi takdirde kritik hatalar gözden kaçabilir, bu da ana iş sürecinin güvenlik açığına yol açar.

Tipik Hatalar ve Antipatternler

Testlerin içsel nesnelere/yapılara, kırılgan seçicilere bağımlılığı.
Olumsuz/alternatif yolların olmaması.
Küçük varyasyonlarla birden fazla tekrarlayıcı test.

Hayattan bir örnek

Olumsuz durum

Projede iş mantığı yalnızca UI Selenium testleri üzerinden test edildi, doğrudan düğmelere ve formlara çalışıldı. Her ön yüz refaktörü, otomatik testlerin kitlesel başarısızlığına neden oldu.

Artıları:

Tüm işlevselliğin hızlı başlangıç kapsama
Senaryoların özünü yönetime kolayca açıklamak

Eksileri:

Kırılganlık: UI'deki en küçük değişiklik her şeyi bozuyor
Yavaş, istikrarsız testler, bakımı zor

Olumlu durum

Projede bir API ve birim testleri katmanı uygulandı. UI yalnızca kritik yolları kapsıyordu, geri kalan tüm validasyon, maliyetli hizmetlerin moke edilerek servis katmanında gerçekleşti.