🏗️ Framework Mimarisi (SOLID + POM)

Framework Mimarisi (SOLID + POM): Bu sekmeye kadar yazdığın her parça (findElement çağrıları, WebDriverWait blokları, @Test metotları) tek tek çalışıyor ama birbirine GEVŞEK bağl

Bu sekmeye kadar yazdığın her parça (findElement çağrıları, WebDriverWait blokları, @Test metotları) tek tek çalışıyor ama birbirine GEVŞEK bağlı — tıpkı imar planı olmadan büyüyen bir sanayi sitesi gibi: her atölye kendi jeneratörünü kurar, kendi su hattını çeker, kimse ortak bir standarda uymaz. İlk 10 testte sorun çıkmaz; 200. testte "acaba bu bekleme kaç saniye?" sorusunun cevabı 200 ayrı yerde saklıdır. Framework mimarisi tam burada devreye girer: TEK bir DriverManager driver yaşam döngüsünü yönetir (ana elektrik şebekesi), TEK bir BasePage tüm bekleme/tıklama mantığını barındırır (ortak bina yönetmeliği), her PageObject SADECE kendi elementlerini bilir (mahalle sınırı). Peki her test zaten WebDriverWait 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: her @Test kendi `new WebDriverWait(driver, Duration.ofSeconds(10))` satırını kopyalarsa, "bekleme süremizi 15 saniyeye çıkaralım" kararı 200 dosyayı elle değiştirmek demektir. Java karşılaştırması: kötü tasarlanmış bir projede her sınıfın kendi `SimpleDateFormat`'ını yaratmasıyla, tek bir merkezi utility sınıfının bunu yönetmesi arasındaki fark tam olarak budur — SOLID prensipleri bu farkı disipline eder. QA bağlamı: flaky test suite'lerinin çoğu zaman GERÇEK sebebi yanlış locator değil, mimarisizliktir; tutarsız bekleme süreleri, kopyalanmış driver kurulumları ve dağınık locator'lar bir araya gelince "bende geçiyor, CI'da patlıyor" kabusu doğar.

Selenium 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 test ç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ı (@DataProvider / ITestContext / config) 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?

TestNG `parallel="methods"` ile testleri aynı anda koşturduğunda, statik tek bir WebDriver alanı OLSAYDI üç thread aynı tarayıcıya yazardı ve testler birbirinin sayfasını bozardı. ThreadLocal sayesinde aynı DriverManager sınıfı her thread'e HİZMET eder ama her thread kendi WebDriver referansını tutar — bir thread bittiğinde diğerlerinin oturumu ETKİLENMEZ.

4️⃣ Veri Paylaşım Kapsamı — Test Verisi Nereden Gelir?

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

🎬 Bir @Test Çağrısının Zinciri (ve Thread-2 Kontrastı)

Thread-2 (paralel test)

`loginTest` metodu çalışmaya başlıyor. Bu metot SADECE senaryoyu anlatır — hiçbir locator veya bekleme kodu içermez, işi doğrudan LoginPage'e devreder.

Adım 1 — LoginPage (POM) devreye girer: kendi `@FindBy` locator'larını bilir ama tıklama/bekleme mantığına HİÇ dokunmaz, onu miras aldığı BasePage'e bırakır.

Adım 2 — BasePage, elemente dokunmadan ÖNCE ortak bekleme kuralını WaitFactory'den ister. Bu SRP sınırıdır: BasePage "nasıl beklenir"i bilmez, sadece "ne zaman beklemesi gerektiğini" bilir.