🏗️ Framework Mimarisi (SOLID + POM)

Framework Mimarisi (SOLID + POM): Selenium ve Playwright'ta bu noktada bir "Page Object Model" sınıfı yazardın — Cypress'in resmi dokümantasyonu ise bunu TAM TERSİNE önerir: klas

Selenium ve Playwright'ta bu noktada bir "Page Object Model" sınıfı yazardın — Cypress'in resmi dokümantasyonu ise bunu TAM TERSİNE önerir: klasik POM sınıfları yerine "Custom Commands" ve "App Actions" kullanmayı tavsiye eder. Neden? Çünkü Cypress, Selenium gibi tarayıcıya UZAKTAN komut GÖNDERMEZ — test kodun, uygulamanın çalıştığı AYNI process'in, AYNI event loop'unun içine enjekte edilir. Bu yüzden "UI üzerinden login ol" akışını her testte tekrar tekrar UI'dan geçirmek yerine, uygulamanın kendi login fonksiyonunu veya API'sini DOĞRUDAN çağırmak hem daha hızlı hem daha az kırılgandır. İkinci benzetme: bir restoranın arka kapısı gibi — müşteri (test) her seferinde ön kapıdan (UI) sıraya girip masaya oturmak yerine, mutfağa bağlı arka kapıdan (API/App Action) doğrudan girip masasına oturabilir; sonuç aynıdır ("müşteri masada, sipariş verebilir") ama yol çok daha kısa ve öngörülebilirdir. Peki UI login testi zaten bir yerde yazılmışken, diğer 79 testte NEDEN yine UI'dan login geçelim — sadece "login çalışıyor mu" testinde UI'ı kullanmak, geri kalan 79 testte arka kapıyı kullanmak yeterli değil mi? Tam olarak öyle: UI login'in KENDİSİ bir kez test edilir, geri kalan senaryolar "kullanıcı zaten giriş yapmış olsun" varsayımıyla başlar. Java karşılaştırması: bu, entegrasyon testlerinde `@Sql` ile veritabanını doğrudan hazırlamakla, HER testte UI üzerinden kayıt oluşturmak arasındaki farkla AYNI motivasyon — durumu hazırlamak senaryo DEĞİLDİR, senaryonun ÖN KOŞULUDUR. QA bağlamı: UI üzerinden login yapan 80 spec dosyası varken login formuna bir CAPTCHA eklenirse 80 dosya aynı anda kırılır; App Actions kullanan bir suite'te SADECE 1 fonksiyon (loginByApi) güncellenir, 80 test hiç değişmeden devam eder.

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

Custom Command / Core Katmanı

"POM" Yerine App Actions

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

Aynı mimari burada beş ayrı açıdan gösteriliyor: önce ana akış (bir test cy.login() çağırdığında ne olur), sonra kurulum akışı (config'ten support dosyasına, oradan spec'e), sonra paralel çalışma (Cypress'in "aynı process" mimarisi Selenium/Playwright'tan NEDEN farklı paralelleşir), sonra veri paylaşım kapsamı (Cypress.env / fixture / custom command scope'u) ve son olarak her dosyanın "yapar/yapmaz" listesi.

3️⃣ Paralel Çalışma — Cypress Neden Selenium/Playwright'tan Farklı Paralelleşir?

Spec Dosyası = İzolasyon Birimi

CI Paralelliği = Makine Seviyesi

Selenium'da ThreadLocal, Playwright'ta worker process'i AYNI koşum içindeki paralelliği yönetirdi. Cypress varsayılan olarak TEK bir tarayıcıda, spec dosyalarını SIRAYLA çalıştırır — "paralellik" burada farklı bir katmana taşınır: Cypress Cloud/Dashboard, bir suite'in spec dosyalarını N farklı CI makinesine böler (`cypress run --record --parallel`), her makine kendi tarayıcısını AYRI process olarak açar. Yani framework mimarin AÇISINDAN önemli olan şey ThreadLocal değil, her spec dosyasının BAŞINDAN SONUNA kendi kendine yetebilmesidir (bir önceki dosyanın state'ine bağımlı olmamalı) — çünkü hangi dosyanın hangi makineye düşeceğini SEN seçmezsin.

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

Cypress.Commands.add(...)

5️⃣ Kim Ne Yapar? — Dosya Sorumlulukları