🏗️ Framework Mimarisi (SOLID + POM)

Framework Mimarisi (SOLID + POM): Bu sekmeye kadar yazdığın her parça (LoginSteps, LoginPage, LocatorRepository, env/ dosyaları) tek tek çalışıyor ama birbirine GEVŞEK bağlı — tı

Bu sekmeye kadar yazdığın her parça (LoginSteps, LoginPage, LocatorRepository, env/ dosyaları) tek tek çalışıyor ama birbirine GEVŞEK bağlı — tıpkı plansız büyüyen bir gecekondu mahallesi gibi: her ev kendi kuyusunu kazar, kendi elektriğini çeker, sokak numaralandırması yoktur. İlk 20 evde sorun çıkmaz; 200. evde su borusu hangi evden geçiyor kimse bilmez. Şehir imar planı (mimari) tam burada devreye girer: ortak altyapı (su/elektrik şebekesi = DriverFactory, TEK yerden yönetilen driver yaşam döngüsü), standart bina kuralları (BasePage = her Page sınıfının uyduğu ortak iskelet), mahalle sınırları (Steps sınıfı SADECE orkestrasyon yapar, Page sınıfı SADECE element bilir). Peki her parça zaten DriverFactory.getDriver() ile aynı driver'ı kullanıyorken, neden ayrı bir mimari sekmesi açıyoruz — parçalar zaten var değil mi? Çünkü VAR OLMAK ile DOĞRU İLİŞKİLENMEK aynı şey değildir: parçalar birbirine rastgele bağlanırsa (her Steps sınıfı kendi driver'ını yaratırsa, her Page sınıfı kendi wait mantığını yeniden yazarsa) 50 dosyalık projede bir bekleme stratejisi değişikliği 50 yeri kırar. Karşılaştırma: kötü tasarlanmış bir Java projesinde "God Object" (her şeyi bilen dev sınıf) ile SOLID prensiplerine göre bölünmüş küçük, tek-sorumluluklu sınıflar arasındaki fark tam olarak budur — bu sekmede o farkı Gauge/Selenium bağlamında somut kod üzerinden göreceksin. QA bağlamı: flaky test suite'lerinin çoğu zaman GERÇEK sebebi yanlış locator değil, mimarisizliktir — yeni bir QA mühendisinin projeye alışması haftalar sürüyorsa, suç genelde yeni katılanda değil, mimaride aranmalıdır.

Framework'ünü Adım Adım İnşa Et

Aşağıdaki 4 parça, bu sekmede birazdan tek tek inşa edeceğin mimarinin BÜYÜK RESMİ. Şimdilik hepsi kilitli — her parçanın kendi adımındaki "Kendin Dene" pratiğini ilk kez doğru bitirdiğinde, o parça burada kilitliden İNŞA EDİLDİ'ye döner. Aşağı indikçe yapbozu parça parça tamamlayacaksın.

🧭 Adım 1 — Büyük Resim: Framework Mindmap

Aynı mimari burada beş ayrı açıdan gösteriliyor: önce ana akış (bir step çalışırken kim kimi çağırır), sonra kurulum akışı (config nereden gelip driver'a nasıl ulaşır), sonra paralel çalışma (ThreadLocal neden var), sonra veri paylaşım kapsamı (DataStore'lar) ve son olarak her sınıfın "yapar / yapmaz" listesi. İlk iki kutuda ▶ Animasyon butonuna basarak akışın adım adım nasıl ilerlediğini izleyebilirsin.

3️⃣ Paralel Çalışma — Neden ThreadLocal?

Aynı DriverFactory sınıfı her thread'e HİZMET eder ama ThreadLocal sayesinde her thread kendi WebDriver referansını tutar — bir thread quitDriver() çağırdığında diğerlerinin oturumu ETKİLENMEZ.

4️⃣ Veri Paylaşım Kapsamı — DataStore'lar

5️⃣ Kim Ne Yapar? — Sınıf Sorumlulukları

Yukarıdaki mimaride bir Steps sınıfı (örn. LoginSteps) WebDriver'ı NEREDEN alır?

Kendi içinde new ChromeDriver() ile yaratır

DriverFactory.getDriver() ile ThreadLocal'dan alır

LocatorRepository sınıfından okur

Her .spec dosyasının başında elle tanımlanır