Playwright mı Cypress mı? Beş senaryoda hız üstünlüğü tek başına yetmiyor

Bağımsız Angular araştırmasının beş senaryoluk süre grafiği, Playwright/Cypress ortalamalarını kullanıcı kaydında 10,33/21,96 saniye, yazma dersinde 16,06/35,67 saniye, Schulz tablolarında 10,77/23,39 saniye, sayı sıralamada 10,92/21,72 saniye ve sorun yönetiminde 15,14/25,93 saniye olarak gösteriyor. Yeni bir uçtan uca (E2E) test paketi için Playwright bu nedenle güçlü bir başlangıç seçeneği; hız farkı, aynı uygulamada ölçülen senaryoların sonucu.

Çalışan ve geniş bir Cypress paketi için karar farklıdır. Testleri taşımak zaman alır; hangi tarayıcıların gerekli olduğu, paketin CI üzerinde nasıl bölündüğü ve hataların nasıl incelendiği de toplam emeği belirler. Tekil testin daha kısa sürmesi, bütün paketi yeniden yazmanın kendiliğinden karşılığını vereceği anlamına gelmez.

Ölçülen süreler neyi kapsıyor?

Senaryolar yalnızca sayfa açıp bir düğmeye basmaktan oluşmuyor. Kayıt akışında doğrulama ve yeniden oturum açma, yazma dersinde ilerlemenin kaydı, Schulz tablolarında oyun etkileşimleri, sayı sıralamada sürükleyip bırakma, sorun yönetiminde ise kullanıcı ile yönetici işlemleri var. Farklı işlevlerin aynı yönde sonuç vermesi, Playwright lehine bulguyu tek bir etkileşime bağlı olmaktan çıkarıyor.

Deney tek bir Angular uygulamasında, yerel bir makinede ve tarayıcı penceresi açılmadan yürütülmüş. Her çalıştırmadan önce uygulama verisini sıfırlamak için özel bir uç nokta kullanılmış; ölçülen süre, test sürecinin başlaması ile bitmesi arasındaki zamanı kapsıyor. Bu kurulum, önceki çalıştırmadan kalan verinin etkisini azaltıyor. Buna karşılık uzaktaki uygulamanın gecikmesi, paylaşılan CI kaynakları ve büyük bir paketteki dosya dağılımı ölçülen koşulların dışında kalıyor.

Grafikte en büyük mutlak süre farkı yazma dersi akışında görülüyor. Bunun nedenini yalnızca test aracına bağlamak doğru olmaz: senaryonun adımları, kullanılan beklemeler ve uygulamanın davranışı da süreye girer. Araştırma, incelenen kurulumda hangi testlerin daha kısa tamamlandığını gösteriyor; başka bir projenin dakika cinsinden CI kazancını doğrudan hesaplamıyor.

Paralellik CI süresini ve kaynak kullanımını nasıl değiştirir?

Çok dosyalı bir pakette sonuç, tek bir senaryonun süresinden farklı olabilir. Playwright’ın paralellik belgesi, test dosyalarının varsayılan olarak ayrı işçi süreçlerinde paralel çalıştığını, aynı dosyadaki testlerin ise varsayılan düzende sırayla yürüdüğünü belirtiyor. Dolayısıyla bağımsız testleri dosyalara dağıtan bir paket ile büyük bir dosyada toplayan paket aynı paralellik avantajını kullanmaz.

Her işçinin yalıtılmış BrowserContext ortamı tarayıcı çerezlerini, depolamayı ve süreç içi durumu ayırır. Fakat ortak veritabanındaki kaydı veya aynı kullanıcı hesabını değiştiren testler yine çakışabilir. Paralel işçi sayısı arttığında veri hazırlığının da buna uygun olması gerekir; aksi halde kısa çalışma süresi, kararsız testleri incelemek için harcanan zamanla dengelenebilir.

Cypress de CI üzerinde tarayıcı gruplarına göre paralel çalıştırılabilir. Cypress’in çapraz tarayıcı rehberi, Chrome ve Firefox gruplarına farklı sayıda CI makinesi ayıran, çalışmaları Cypress Cloud üzerinden kaydeden bir örnek veriyor. Aynı rehber, kritik testlerin farklı tarayıcılarda farklı sıklıklarla koşulabileceğini de gösteriyor. Bu yüzden araçları karşılaştırırken yalnızca testin bitmesini beklediğiniz süreye değil, kullanılan makine süresine ve seçilen hizmetlere de bakmak gerekir.

Paralel çalıştırma özellikle büyük bir paketin bekleme süresini azaltabilir; kaynak tüketimi ise işçi ve makine sayısıyla birlikte değişir. Playwright’ın varsayılan dosya paralelliği ile Cypress’in CI gruplaması aynı kurulum değildir. Anlamlı karşılaştırma, eşdeğer test kapsamı ve ayrılmış kaynaklarla tamamlanan bütün paketin süresidir.

WebKit gereksinimi seçimi nasıl etkiler?

Chrome ailesi ve Firefox hedeflendiğinde her iki araç da değerlendirmeye girer. Safari davranışını WebKit üzerinden düzenli olarak sınamak gerekiyorsa destek statüsü daha belirleyici olur: Cypress’in tarayıcı başlatma belgesi WebKit desteğini deneysel olarak tanımlıyor; etkinleştirme ayarı ve ayrıca kurulacak playwright-webkit paketi gerekiyor. Belgede cy.origin() ve Test Replay gibi özellikler için WebKit sınırlamaları da listeleniyor.

Bu ayrım, tarayıcı listesindeki bir işaretten daha somut bir seçim ölçütüdür. WebKit testleri sürüm öncesi zorunlu bir kapıysa deneysel desteğin ilgili akışlarda nasıl davrandığı önem kazanır. Yalnızca dönemsel uyumluluk kontrolü yapılıyorsa tarayıcı kapsamını mevcut Cypress paketinin tamamına yaymak gerekli olmayabilir. Hangi akışın hangi tarayıcıda ve ne sıklıkta koşacağı, araç seçiminden ayrı bir CI kararıdır.

Araştırmada her iki araç Chrome, Firefox ve WebKit ortamlarında çalıştırılmış olsa da bu, ürün belgelerindeki destek statülerini eşitlemez. Deneyin başarıyla yürütülmüş olması belirli uygulama ve test adımları için bir bulgudur; sürekli kullanılan bir test paketinde gereken özellikler ve bakım koşulları ayrıca hesaba katılır.

Hata ayıklama süresi neden hız hesabına girer?

Yerel geliştirme sırasında Cypress’in görünür komut geçmişi önemli olabilir. Cypress açık mod belgesi, Command Log içindeki komutların uygulama durumunun anlık görüntülerine bağlandığını; bir komutun üzerine gelerek o andaki durumun incelenebildiğini anlatıyor. Seçici, form ve etkileşim hatalarında sorunun hangi adımda başladığını görmek için bu akış kullanılabilir.

Çalışma süresi grafiği bu inceleme emeğini ölçmüyor. Testler sık sık yerelde düzeltiliyorsa komut geçmişinin ekibe kazandırdığı zaman, tekil yürütme farkıyla birlikte düşünülmeli. Hatalar daha çok CI’da ortaya çıkıyorsa kayıtların saklanması, erişimi ve yeniden üretilebilirliği önem kazanır. Böylece hata ayıklama tercihi, bir aracın arayüzünü beğenme meselesinden çıkıp ekibin hatayı nerede çözdüğü sorusuna bağlanır.

Yeni projede ve mevcut pakette hangi seçim daha güçlü?

Yeni projede Playwright lehine gerekçe güçlüdür: incelenen Angular uygulamasında bütün senaryolar daha kısa sürmüş, test dosyaları varsayılan olarak paralel çalıştırılabiliyor ve tarayıcı bağlamları işçiler arasında ayrılıyor. Çok sayıda bağımsız test dosyası planlayan, WebKit’i düzenli kapsamda tutan ve CI geri bildirimini hızlandırmak isteyen ekip için bu özellikler aynı yönde çalışır. Beklenen kazancın büyüklüğü ise uygulamanın kendi akışlarına ve ayırabileceği CI kaynaklarına bağlıdır.

Mevcut Cypress paketi büyük ve kararlıysa geçiş hesabına çalışan testlerin değeri de girer. Komutları çevirmekle iş bitmez: seçiciler, yardımcı işlevler, oturum hazırlığı, ağ taklitleri ve hata inceleme alışkanlıkları yeni düzende yeniden kurulabilir. Mevcut CI darboğazı yalnızca tarayıcı kapsamından veya yetersiz paralellikten kaynaklanıyorsa Cypress içindeki tarayıcı grupları ile test seçimini düzenlemek, kapsamı baştan taşımaktan daha az emek gerektirebilir. Geçişin gerekçesi, tek uygulamadaki saniyeler yerine sürdürülecek paketin toplam süresi ve bakım yükü olmalıdır.

Ayrıca okuyun:

• Google Etkinliğim’i silmek yetmiyor: Tarayıcı geçmişi ayrı kalıyor
• Jalapeño watt başına önde, fakat Blackwell karşılaştırması eksik
• AI influencer platformunda “ajan” yetmez: Beş iş akışını karşılaştırın