Tarayıcı Kapsamı ve Mimari Farkı
Playwright resmi dokümana göre "Chromium, WebKit ve Firefox'u Windows, Linux ve macOS'ta, yerel ya da CI'da, headless ya da headed olarak destekler, Chrome (Android) ve Mobile Safari için native mobil emülasyonla birlikte." Bu üç motor desteği mimariden geliyor — Playwright tarayıcıyı CDP-benzeri bir protokolle dışarıdan kontrol ettiği için her motoru aynı API yüzeyiyle sürer.
Cypress'te tablo farklı: Chrome ailesi ve Firefox tam destekli, ama WebKit hâlâ "Experimental" statüde ve Electron kullanımdan kaldırılmış. Neden mimari — Cypress test kodu tarayıcının içinde, uygulamanla aynı event loop'ta çalışır; bu Chrome/Firefox'ta olgunlaştı ama WebKit entegrasyonu aynı seviyede değil.
Pratik sonuç: gerçek Safari/iOS kullanıcı tabanı olan bir ürün test ediyorsan Playwright'ın WebKit desteği bugün daha güvenilir. Ama dikkat — WebKit, Apple'ın gerçek Safari binary'si değil; bazı Safari-özel davranışlar WebKit testinde yakalanmayabilir.
Paralellik, CI Süresi ve Maliyet
Playwright'ın dokümanı açık: "Playwright Test testleri paralel çalıştırır... birden fazla worker process başlatır... her biri kendi tarayıcısını başlatır." Bu paralellik --workers N bayrağıyla, ek bir bulut servisi olmadan, tamamen yerel ve ücretsiz çalışır. Microsoft'un ayrı ücretli bulut servisi (Azure App Testing) var ama isteğe bağlı bir ölçekleme katmanı, temel paralelliğin önkoşulu değil.
Cypress'te cypress run --parallel mevcut ve fiyatlandırma tablosuna göre paralel koşum ücretsiz Starter katmanında da var (aylık 500 test sonucu, --record ile Cloud'a bağlı). Load balancing de ücretsiz katmanda: --record --parallel ile varsayılan açık. Kademeli olan yalnız auto cancellation ve spec prioritization (Business'tan itibaren). Yani paralellik ve akıllı dağıtım için bedel ödemiyorsun, ama her koşumu Cloud'a kaydetmek zorundasın.
Sayısal CI maliyeti için dürüst olalım: hiçbir taraf resmi, karşılaştırmalı bir "dakika başına maliyet" benchmark'ı yayınlamıyor. Azure App Testing'in fiyat tablosu bu araştırmada doğrulanamadı; üçüncü taraf $/dakika rakamlarına resmi kaynak olmadan güvenme.
Debug Deneyimi: Trace Viewer vs Time Travel
Playwright'ın Trace Viewer'ı, kayıtlı bir test çalışmasını adım adım gezebildiğin bir GUI aracı; varsayılan trace: 'on-first-retry' ile başarısız testlerde otomatik devreye girer. 4 Eylül'de gelen v1.63.0 ile trace'e DOM/ARIA/ekran görüntüsü snapshot'ları ve "Display Aria" modu eklendi — artık görsel ekranı ve erişilebilirlik ağacını yan yana inceleyebiliyorsun.
Cypress'in güçlü yanı "Time Travel" — testin her adımında DOM anlık görüntüsü alıp geri sarabilme, tanıdık DevTools içinde. Cypress Cloud'daki Test Replay bunu ileri taşıyor: CI'da başarısız bir testin DOM/network/console durumunu birebir tekrar oynatabiliyorsun. Resmi vaka çalışmasına göre Indeed, Test Replay ile debug süresini %50 azalttığını raporluyor.
İkisi de güçlü ama farklı problemler çözüyor: Playwright'ın trace'i taşınabilir bir kanıt dosyası; Cypress'in Time Travel + Replay'i o anı birebir geri getirme. Ekibinin alışkanlığı hangisinin daha doğal hissettireceğini belirler.
Cross-Origin, iframe ve Çoklu Sekme
Bu kriter Cypress'in tarihsel olarak en çok eleştirilen noktası. Resmi doküman şöyle özetliyor: "Cypress tarayıcının içinden çalıştığı için, uzak uygulamanla her zaman doğrudan iletişim kurabilmesi gerekir... tarayıcılar doğal olarak bunu engellemeye çalışır." Bu kısıt yüzünden cross-origin senaryoları (ör. bir OAuth sağlayıcısına yönlenip geri dönme) özel bir API olan cy.origin() ile yönetilmesi gerekiyor — mimari bir sınırlama, her cross-origin akışında ek kod demek.
Playwright'ta bu kökten farklı çözülüyor: browser.newContext() ile izole context'ler ve doğal çoklu sekme/pencere desteği mimarinin bir parçası. 4 Eylül'de gelen v1.63.0 ile bu alan güçlendi — page.frameLocator() artık selector'sız çağrıldığında **tüm alt-frame ağacında arama yapıyor**, iç içe iframe'lerde her frame'i tek tek gezmen gerekmiyor.
Pratikte: SSO/OAuth'a yönlenen, ödeme iframe'i gömen ya da yeni sekmede açılan akışlar test ediyorsan, Playwright'ın mimarisi bunları ekstra API öğrenmeden karşılıyor.
Ağ Mocking, API Testi ve Dil Desteği
Her iki araç da olgun ağ mock yetenekleri sunuyor, ama ergonomi farklı. Playwright'ta hiçbir ek yapılandırma gerekmiyor: "İstek mock'lamak için hiçbir şey yapılandırmana gerek yok. Sadece context.route() / page.route() ile özel bir Route tanımla." HAR dosyalarından mock'lama da resmi destekli — prod trafiğini kaydedip testte tekrar oynatmak isteyenler için pratik.
Cypress'te eşdeğer araç cy.intercept() — istek/yanıt stub'lama, URL/header/body assertion yapabiliyorsun. 16.0.0 ile Chrome ailesinde native network interception'a geçildi; bu, bazı düşük seviye header bilgilerinin artık eski davranışla aynı gelmediği anlamına geliyor — mevcut assertion'ların sessizce yanlış sonuç vermemesi için bu geçişi test etmen gerekiyor.
Dil desteği net bir Playwright avantajı: "Playwright, aynı temel implementasyonu paylaşan birden fazla dilde mevcut" — JS/TS, Python (pytest), Java, .NET resmi destekli, her biri ayrı repo'da. Cypress mimarisi gereği yalnızca JS/TS'te yazılıyor; ekibinde Python/.NET ağırlıklı mühendisler varsa bu belirleyici olabilir.
Component Testing Olgunluğu
Bu, Cypress'in şu an resmi kaynaklarla desteklenen net bir üstünlüğü. Cypress'in tanımıyla: "Cypress Component Testing, bileşenlerini gerçek bir tarayıcıda doğrudan mount eder — simüle edilmiş bir DOM değil." Time Travel debug, DevTools entegrasyonu ve React/Vue/Angular/Svelte için resmi, bakımı yapılan adaptörler mevcut.
Playwright tarafında durum daha hareketli: @playwright/experimental-ct-react, -ct-react17 ve -ct-vue paketleri resmi olarak kaldırıldı, artık yayınlanmıyor. Yerine framework-agnostic, JSX gerektirmeyen yeni bir mount() fixture'ı geldi. Bilinçli bir mimari değişim, ama şu an component testing'i Playwright'ta kuran bir ekip Cypress'teki kadar hazır-paket bir deneyim bulamıyor.
Sonuç: ürününün büyük kısmı component-seviyesinde test edilen bir frontend ekibiysen (özellikle React/Vue/Angular çeşitliliği varsa) Cypress'in bu kriterde bugün daha olgun, resmi kaynaklı bir avantajı var. Playwright bu alanda yeniden mimarileniyor — birkaç sürüm sonra tablo değişebilir.
Göç Maliyeti: Cypress'ten Playwright'a
Playwright tarafında resmi bir "Cypress'ten Playwright'a geçiş rehberi" yok; ters yönde ise Cypress'in resmi "Migrate from Playwright" rehberi var. Yani göç dokümantasyonu simetrik değil, Playwright'a giden yolu kendin kurgulamak zorundasın. Bu araştırmada net bir gün/hafta rakamı da çıkmadı, dürüstçe "belirsiz" diyelim. Var olan yardımcı: Playwright'ın demo alan adında yayınlanan demo.playwright.dev/cy2pw dönüştürücüsü, tek dosya bazlı çalışıyor; tam otomatik bir codemod değil.
Mimari fark, göçün neden mekanik bir "bul-değiştir" olmadığını açıklıyor: Cypress'in cy.get().should() zincirleri tarayıcı-içi otomatik retry'a dayanıyor; Playwright'ın page.locator().expect() API'si benzer bir "auto-wait" felsefesi paylaşsa da birebir çevrilemiyor — özellikle cy.origin() kullanan testler, custom komutlar ve component testleri elle gözden geçirilmeli.
Gerçekçi yol haritası: kritik akışları önce taşı, tüm suite'i tek seferde çevirme; iki suite'i bir süre paralel çalıştır; mekanik dönüşümü codemod/AI ile hızlandır ama elle gözden geçir; custom komutları ve component testlerini son sıraya bırak. "Hafta sonu rewrite" beklentisi orta-büyük bir suite için gerçekçi değil.