Yeşil Mimari Testler Neden Hataları Kaçırabilir?

Yeşil Mimari Testler Neden Hataları Kaçırabilir?

Mimari testleriniz yeşil yanıyor ama sisteminiz canlı ortamda beklenmedik hatalar mı veriyor? Statik mimari testlerinin görmediği kör noktaları ve dinamik yazılım hatalarını engellemenin yollarını bu yazıda detaylarıyla keşfedin.

Mimari Test (Architecture Test) Nedir ve Neden Yeşil Yanar?

Yazılım geliştirme süreçlerinde kod kalitesini korumak ve mimari prensiplere sadık kalmak her geçen gün daha zor bir hale geliyor. Özellikle büyük ölçekli projelerde, ekipler büyüdükçe mimari kuralların ihlal edilmesi kaçınılmaz olabiliyor. İşte bu noktada devreye mimari testler (Architecture Tests) giriyor. ArchUnit (Java dünyasında) veya NetArchTest (.NET dünyasında) gibi araçlar sayesinde, kod tabanımızın belirlediğimiz mimari kurallara uyup uymadığını otomatik olarak denetleyebiliyoruz.

Peki, bir mimari testin “yeşil yanması” tam olarak ne anlama gelir? Yeşil renk, tanımladığınız kurallar çerçevesinde derleme zamanında (compile-time) veya statik analiz seviyesinde herhangi bir kural ihlali tespit edilmediğini gösterir. Örneğin, Controller katmanının doğrudan Repository katmanına erişmemesi gerektiğini belirten bir test yazdıysanız ve kodda böyle bir doğrudan bağımlılık yoksa, test başarıyla geçer ve yeşil ışık yakar. Bu durum geliştiricilere ciddi bir özgüven sağlar.

Ancak, bu yeşil ışık her zaman yazılımınızın kusursuz çalıştığı anlamına gelmez. Çünkü mimari testler temel olarak kodun statik yapısını ve bağımlılık grafiğini analiz eder. Kodun çalışma zamanında (runtime) sergileyeceği davranışları, veri akışını veya performans darboğazlarını ölçemez. Bu nedenle, test raporunda baştan sona yeşil renk görseniz bile, sisteminiz canlıya çıktığında mimari düzeyde büyük felaketlerle karşılaşabilirsiniz.

Yeşil Yanan Testler Bizi Nasıl Yanıltır?

Yazılım ekipleri genellikle yeşil yanan test sonuçlarını görünce psikolojik bir rahatlama yaşarlar. Bu durum literatürde “yanlış güvenlik hissi” (false sense of security) olarak adlandırılır. Ancak statik analiz araçları ve mimari test kütüphaneleri, kodun sadece görünen yüzünü inceler. Kodun arkasındaki niyet veya dinamik çalışma mekanizmaları bu testlerin gözünden kaçabilir.

Özellikle nesne yönelimli programlama (OOP) ve modern yazılım mimarilerinde esneklik sağlamak amacıyla kullanılan bazı teknikler, mimari testlerin kapsama alanının dışına çıkar. Örneğin, bağımlılıkların çalışma zamanında çözümlenmesi veya olay tabanlı (event-driven) iletişim mimarileri, statik bağımlılık grafiklerinde görünmezler. Bu durum, mimari kurallarınızın kağıt üzerinde kusursuz işlemesini sağlarken, arka planda mimari prensiplerinizin çiğnenmesine zemin hazırlar.

Ayrıca, geliştiricilerin farkında olmadan veya acil iş teslimi baskısıyla yazdığı bazı “dolaylı çözümler” (workaround) mimari test kütüphanelerini kolaylıkla kandırabilir. Test kütüphanesi kodun A sınıfından B sınıfına doğrudan referans vermediğini doğrular. Fakat geliştirici A sınıfı içinden B sınıfını dinamik olarak çağırıyorsa, test bunu fark edemez ve yeşil yanmaya devam eder.

Dinamik Çağrılar ve Yansıma (Reflection) Tehlikesi Nasıl Aşılır?

Yansıma (Reflection), bir programın çalışma zamanında kendi yapısını incelemesine ve değiştirmesine olanak tanıyan güçlü bir özelliktir. Ne var ki, bu güç mimari testlerin en büyük düşmanıdır. Statik mimari testler, derlenmiş kodun bağımlılık matrisine bakar. Bir sınıf başka bir sınıfı açıkça import veya using ifadeleriyle çağırmıyorsa, test aracı bu iki sınıf arasında bağımlılık olmadığını varsayar.

Aşağıdaki C# örneğini inceleyelim. Senaryomuza göre Domain katmanımızın kesinlikle Altyapı (Infrastructure) katmanına erişmemesi gerekmektedir. Yazdığımız mimari test bu kuralı denetlemektedir:

// Mimari Kural: Domain katmanı Infrastructure katmanına bağımlı olamaz!
var result = Types.InCurrentDomain()
    .That()
    .ResideInNamespace("MyProject.Domain")
    .ShouldNot()
    .HaveDependencyOn("MyProject.Infrastructure")
    .GetResult();

Assert.IsTrue(result.IsSuccessful); // Bu test YEŞİL yanacaktır.

Ancak, domain içerisindeki bir servis geliştiricisi, mimari kuralı doğrudan çiğnemek yerine Yansıma (Reflection) kullanarak altyapı katmanındaki bir veritabanı servisini şu şekilde çağırırsa ne olur?

namespace MyProject.Domain.Services
{
    public class OrderService
    {
        public void ProcessOrder()
        {
            // Statik referans yok, yansıma ile çalışma zamanında yükleme yapılıyor!
            var assembly = Assembly.Load("MyProject.Infrastructure");
            var type = assembly.GetType("MyProject.Infrastructure.Data.SqlDbContext");
            var dbInstance = Activator.CreateInstance(type);
            
            // Veritabanı işlemleri doğrudan Domain içinde yürütülüyor
            type.GetMethod("SaveData")?.Invoke(dbInstance, null);
        }
    }
}

Bu senaryoda yukarıdaki mimari test tamamen YEŞİL yanacaktır. Çünkü statik analiz aşamasında OrderService sınıfı MyProject.Infrastructure assembly’sine açık bir bağımlılık göstermemektedir. Bağımlılık tamamen çalışma zamanında (runtime) metin tabanlı (string-based) olarak oluşturulmuştur. Sonuç olarak mimariniz delinmiş, katmanlı mimari ilkeleriniz ihlal edilmiş ama testleriniz başarıyla geçmiş olur.

Gerçek Dünya Vaka Analizi: Yerel Bir E-Ticaret Platformunun Çöküşü

Konuyu daha net kavramak adına Türkiye’de faaliyet gösteren orta ölçekli bir e-ticaret platformunun yaşadığı gerçek bir olay inceleyelim. Şirket, yoğun indirim dönemlerinde (Efsane Cuma gibi) sistemin çökmesini engellemek için mikro servis mimarisine geçiş yapmaya karar verdi. Sipariş servisi ile Stok servisi mantıksal olarak birbirinden ayrıldı.

Sistem mimarları, servislerin birbirinin veritabanına doğrudan erişmesini engellemek amacıyla sıkı ArchUnit testleri yazdılar. Test kütüphanesi, Sipariş servisinin Stok servisinin veritabanı sürücülerine ve modellerine erişmediğini doğruluyordu. Bütün CI/CD süreçlerinde mimari testler %100 başarıyla geçiyordu (tamamen yeşildi).

Ancak kampanya gecesi sistem kilitlendi ve siparişler alınamadı. Olay sonrası yapılan kök neden analizinde (Root Cause Analysis) ortaya çıkan tablo oldukça şaşırtıcıydı:

• Yazılım ekibi, mikro servisler arasında veri senkronizasyonu sağlamak için ortak bir mesaj kuyruğu (Event Bus) kullanmıştı.
• Mimari testler veritabanı seviyesinde bağımlılığı engellemişti fakat mesaj yapısındaki nesneler (DTO) dinamik olarak ortak bir JSON şeması üzerinden iki servis tarafından da eşzamanlı kilitlenerek (locking) kullanılıyordu.
• Stok servisi veri formatını değiştirdiğinde, Sipariş servisi derleme zamanında hata almamış, mimari testleri yeşil kalmış ancak çalışma zamanında mesajları işleyemeyerek çökme yaşamıştı.

Bu vaka gösteriyor ki, mimari testlerin yeşil kalması, servislerinizin çalışma zamanındaki davranışsal bağımsızlığını ve dayanıklılığını garanti etmez.

Mimari Testlerin Göremediği 4 Kritik Kör Nokta Nedir?

Mimari test kütüphaneleri kodun sözdizimsel (syntactic) yapısına odaklanır. Ancak bir yazılım mimarisi sadece kod organizasyonundan ibaret değildir. Aşağıdaki tabloda statik mimari testlerin kapsama alanı ile çalışma zamanı gerçekleri arasındaki farklar özetlenmiştir:

Bu kısıtlamaları aşmak için mimari doğrulamayı tek bir test katmanına bırakmamak gerekir. Statik mimari testlerin göremediği dört temel kör noktayı şu şekilde sıralayabiliriz:

1. Çalışma Zamanı Veri Akışı: Statik testler verinin değişkenler üzerinden nasıl aktığını takip edemez. Gizli veri sızıntıları bu nedenle gözden kaçar.
2. Performans ve Thread Tıkanmaları: İki katmanın birbirini kurallara uygun şekilde çağırması, bu çağrının 5 saniye sürmeyeceği anlamına gelmez.
3. Yapılandırma (Configuration) Hataları: Uygulamanın appsettings.json veya application.yml dosyalarındaki yanlış yapılandırmalar mimariyi çökertebilir ama statik kopyalama testlerinde fark edilmez.
4. Dağıtık Sistem İletişimi: HTTP çağrıları, gRPC veya mesaj kuyrukları üzerinden kurulan bağlar kod seviyesinde soyutlandığı için statik testlerin radarından kaçar.

Etkili Bir Mimari Doğrulama Stratejisi Nasıl Kurulur?

Sadece statik testlere güvenmek yerine, çok katmanlı bir mimari doğrulama (Architectural Verification) stratejisi benimsenmelidir. Neal Ford ve Rebecca Parsons tarafından kavramsallaştırılan “Evrimsel Mimari” (Evolutionary Architecture) yaklaşımı, mimariyi korumak için “Mimari Uygunluk Fonksiyonları” (Architecture Fitness Functions) kullanılmasını önerir.

Güçlü bir doğrulama stratejisi oluşturmak için şu adımları izleyebilirsiniz:

1. Statik Mimari Testleri Gelişmiş Kurallarla Zenginleştirin

Sadece katman isimlerine bakmak yerine, kodun özniteliklerini (Attributes/Annotations) ve arayüz uygulayan sınıfları kapsayacak derinlemesine kurallar yazın. Örneğin, sadece isim alanı (namespace) kontrolü yapmayın; sınıfların erişim belirteçlerini (public/internal) de sınırlayın.

2. Entegrasyon ve Sözleşme Testleri (Contract Testing) Ekleleyin

Servislerin birbiriyle nasıl konuştuğunu doğrulamak için Pact gibi araçlarla Tüketici Odaklı Sözleşme Testleri (Consumer-Driven Contract Tests) yazın. Böylece çalışma zamanındaki veri formatı uyumsuzluklarını derleme aşamasına yakın bir noktada yakalayabilirsiniz.

3. Canlı İzlenebilirlik (Observability) ve APM Kullanın

Mimari ihlaller canlı ortamda kendilerini yüksek gecikme (latency) veya hatalı istek sayıları ile belli eder. OpenTelemetry, Jaeger veya New Relic gibi araçlar kullanarak çalışma zamanındaki gerçek mimari bağımlılık haritanızı (Service Map) çıkarın. Bu haritayı kağıt üzerindeki mimariniz ile karşılaştırın.

Kod Örneği ile Katmanlı Mimari İhlalini Yakalama

Aşağıdaki örnekte, yüzeysel bir mimari kural ile daha gelişmiş ve ihlalleri engellemeye yönelik bir mimari kuralın farkını C# kütüphanesi olan NetArchTest ile inceleyelim.

Öncelikle sıradan ve kolaylıkla baypas edilebilen zayıf bir test örneği:

// ZAYIF TEST: Sadece isim alanına bakar, dolaylı erişimleri kaçırabilir.
[Test]
public void Domain_Should_Not_Depend_On_Infrastructure_Weak()
{
    var result = Types.InCurrentDomain()
        .That()
        .ResideInNamespace("MyApplication.Domain")
        .ShouldNot()
        .HaveDependencyOn("MyApplication.Infrastructure")
        .GetResult();

    Assert.IsTrue(result.IsSuccessful);
}

Şimdi ise aynı kuralın, arayüz sızıntılarını ve iç türlerin (internal types) dışarıya sızmasını engelleyen daha kapsamlı versiyonunu inceleyelim:

// GÜÇLÜ TEST: Hem bağımlılığı hem de soyutlama ihlallerini denetler.
[Test]
public void Domain_Layer_Must_Be_Completely_Isolated()
{
    var types = Types.InCurrentDomain();

    // 1. Doğrudan bağımlılık kontrolü
    var dependencyResult = types
        .That()
        .ResideInNamespace("MyApplication.Domain")
        .ShouldNot()
        .HaveDependencyOnAny("MyApplication.Infrastructure", "MyApplication.WebAPI")
        .GetResult();

    // 2. Domain içindeki sınıfların kalıtım ve arayüz kontrolü
    var interfaceResult = types
        .That()
        .ResideInNamespace("MyApplication.Domain")
        .And()
        .AreClasses()
        .Should()
        .NotBeCustomAttributes()
        .GetResult();

    Assert.IsTrue(dependencyResult.IsSuccessful, "Domain katmanında doğrudan altyapı bağımlılığı tespit edildi!");
    Assert.IsTrue(interfaceResult.IsSuccessful, "Domain katmanı standart dışı öznitelikler içeriyor!");
}

Bu şekilde yazılan detaylı testler, geliştiricilerin katmanları istismar etme ihtimalini oldukça azaltır. Yine de unutulmamalıdır ki, kod seviyesindeki önlemler çalışma zamanı kısıtları ile desteklenmelidir.

İleri Düzey Mimari Test İpuçları ve Püf Noktaları

Deneyimli yazılım mimarları ve kıdemli geliştiriciler için projelerde uygulanabilecek bazı ileri düzey teknikler şunlardır:

• Mutasyon Testi (Mutation Testing) Uygulayın: Birim testler için kullanılan mutasyon testi mantığını mimari kural testlerinize de uygulayın. Mimari kuralınızı bilerek ihlal eden geçici bir kod yazın ve mimari testinizin bu hatayı yakalayıp patladığını (kırmızıya döndüğünü) doğrulayın. Testinizin başarısız olabildiğini görmeden yeşil renge güvenmeyin.
• Internal Erişim Belirteçlerini Kullanın: Katmanlar arası gereksiz erişimi engellemenin en köklü yolu kod seviyesindeki kapsüllemedir (encapsulation). C#’taki internal veya Java’daki package-private erişim belirteçlerini aktif kullanın. Sınıflarınız dış dünyaya kapalı olursa, mimari testlerin onları korumasına gerek kalmaz.
• Fitness Function Trendlerini Takip Edin: Mimari testlerinizi sadece geçti/kaldı (pass/fail) olarak değerlendirmeyin. Kod tabanındaki karmaşıklık (Cyclomatic Complexity) ve tight-coupling (sıkı bağlılık) skorlarını sürekli ölçün. Bu skorların zaman içindeki değişim grafiğini CI/CD panelinizde takip edin.

Sonuç

Yazılım geliştirmede yeşil yanan bir mimari test, projenizin doğru yolda olduğuna dair harika bir işarettir; fakat nihai bir garanti değildir. Statik analiz araçları kodun sadece anlık fotoğrafını çeker. Kodun çalışma zamanında sergileyeceği dinamik davranışlar, performans darboğazları ve yansıma (reflection) gibi yöntemlerle oluşturulan gizli bağımlılıklar yeşil testlerin arkasına gizlenebilir.

Özetle, mimari testlerinizi sistem kalitesini artıran önemli bir araç olarak görmeli, ancak tek doğruluk kaynağı olarak kabul etmemelisiniz. Statik mimari testleri; entegrasyon testleri, dinamik analizler, izlenebilirlik (observability) araçları ve düzenli kod gözden geçirme (code review) süreçleriyle destekleyerek yazılımlarınızın hem derleme zamanında hem de canlı ortamda mimari olarak güçlü kalmasını sağlayabilirsiniz.

Sıkça Sorulan Sorular (SSS)

1. Mimari testler birim testlerin (Unit Test) yerini alır mı?

Hayır, mimari testler ve birim testler tamamen farklı amaçlara hizmet eder. Birim testler iş mantığının (business logic) doğruluğunu denetlerken, mimari testler kodun yapısını, katmanların ilişkilerini ve tasarım kurallarını denetler. İki test türü birbirini tamamlayıcı niteliktedir.

2. Testlerin yeşil yanmasına rağmen sistem çöküyorsa ilk neye bakılmalı?

İlk olarak çalışma zamanı (runtime) bağımlılıklarına, bellek tüketimine ve veritabanı kilitlenmelerine (deadlocks) bakılmalıdır. Ayrıca sistemin mikro servisler veya modüller arasındaki asynchronous (eşzamansız) iletişim süreçlerinde veri uyumsuzluğu yaşayıp yaşamadığı APM araçları üzerinden incelenmelidir.

3. Hangi mimari test kütüphanelerini tercih etmeliyiz?

Java ekosisteminde çalışıyorsanız ArchUnit, .NET platformunda geliştirme yapıyorsanız NetArchTest veya ArchUnitNET kütüphanelerini tercih edebilirsiniz. Python projeleri için ise pytest-archon popüler seçenekler arasındadır.

4. Mimari testleri CI/CD süreçlerine nasıl entegre etmeliyiz?

Mimari testler son derece hızlı çalışan statik testlerdir. Bu nedenle CI/CD hattınızın (pipeline) en başında, yani “Build” ve “Unit Test” aşamasında çalıştırılmalıdır. Böylece mimariyi ihlal eden bir Pull Request (PR) henüz ana koda merge edilmeden otomatik olarak reddedilebilir.

#Teknoloji #YazılımMimarisi #CleanCode #WebGeliştirme #YazılımTestleri