🏗️ Framework Mimarisi (SOLID + POM)

Framework Mimarisi (SOLID + POM): Selenium'da bu noktada "her thread kendi driver'ını nasıl alır?" sorusuna DriverManager + ThreadLocal ile cevap verirdin.

Selenium'da bu noktada "her thread kendi driver'ını nasıl alır?" sorusuna DriverManager + ThreadLocal ile cevap verirdin. Playwright'ta bu soru hiç SORULMAZ çünkü her worker zaten kendi işletim sistemi process'ine ve kendi tarayıcı örneğine sahiptir — izolasyon senin yazdığın kodun değil, test runner'ın garantisidir. Peki o zaman Playwright'ta "framework mimarisi" neden hâlâ ayrı bir konu — her şey otomatik değil mi? Otomatik olan SADECE izolasyon; her testin `new LoginPage(page)` yazması, login akışının 80 dosyaya kopyalanması, "önce çerez bannerını kapat" gibi tekrarlayan kurulum adımlarının HER spec dosyasında yeniden yazılması otomatik ÇÖZÜLMEZ. İkinci benzetme: `test.extend` ile kurduğun custom fixture'lar bir otelin vale park hizmetidir — sen anahtarı (page nesnesini) elden ele taşımazsın (Selenium'daki ThreadLocal gibi), resepsiyona (test fonksiyonunun parametre listesine) sadece ihtiyacın olan şeyin adını (`loginPage`) söylersin, vale (fixture resolver) arabayı (nesneyi) HAZIR biçimde kapıya getirir. Java karşılaştırması: bu tam olarak Spring'in `@Autowired` / constructor injection felsefesidir — nesneyi elle `new` yapmak yerine container'a "bana bunu ver" dersin, container bağımlılık zincirini SENİN yerine çözer. QA bağlamı: fixture'sız bir Playwright projesinde "login ol, cookie bannerını kapat, dashboard'a git" gibi 6 satırlık kurulum kodu 80 spec dosyasının HER birinde tekrarlanır; login akışı değişince 80 dosya elle taranır. Fixture ile bu kurulum TEK dosyada durur, 80 spec hiç değişmeden yeni davranışı otomatik alır.

Playwright 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.

Fixture / Core Katmanı

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

Aynı mimari burada beş ayrı açıdan gösteriliyor: önce ana akış (bir test çalışırken loginPage nesnesi nereden gelir), sonra kurulum akışı (config'ten fixture dosyasına, oradan spec'e), sonra paralel çalışma (worker izolasyonu ThreadLocal'a neden ihtiyaç BIRAKMAZ), sonra veri paylaşım kapsamı (test/worker fixture scope + storageState) ve son olarak her dosyanın "yapar/yapmaz" listesi.

3️⃣ Paralel Çalışma — Worker İzolasyonu ThreadLocal'ın Yerini Nasıl Alır?

Selenium'da paralel koşum, AYNI process içinde birden fazla thread çalıştırır — bu yüzden "hangi thread'in hangi driver'ı kullandığı" karışmasın diye ThreadLocal'a ihtiyaç vardı. Playwright'ta her worker AYRI bir process olduğu için bu karışma DAHA BAŞTAN imkânsızdır: Worker-2'nin belleğine Worker-1'in hiçbir değişkeni sızamaz. Bu, framework mimarisini kolaylaştırır ama ORTADAN KALDIRMAZ — fixture'ların kendisi hâlâ doğru kurulmalı, çünkü her worker KENDİ İÇİNDE birden fazla testi sırayla (veya `fullyParallel` ile paralel) çalıştırır.

4️⃣ Veri Paylaşım Kapsamı — Fixture'ın Ömrü Ne Kadar?

5️⃣ Kim Ne Yapar? — Dosya Sorumlulukları

test dosyası (*.spec.ts)

playwright.config.ts

🎬 loginPage Fixture'ı Bir Teste Nasıl Ulaşır? (ve Worker-2 Kontrastı)

page fixture (built-in)