Uçtan Uca Testte Cypress mi Playwright mi: Hangisini Ne Zaman Seçmeli

Mimari fark, özellik farkından önemlidir

Cypress ve Playwright karşılaştırmaları genelde özellik listesiyle başlar: kaç tarayıcı destekliyor, hangi dilde test yazılıyor, paralel çalışıyor mu. Ama asıl belirleyici fark daha derindir ve listelenen özelliklerin çoğunu açıklar.

Cypress, test kodunu tarayıcının kendi çalışma döngüsü içinde çalıştırır. Test ve uygulama aynı JavaScript ortamını paylaşır, Cypress araya bir proxy katmanı koyarak ağ isteklerini ve DOM'u izler. Bunun getirisi büyük: komutlar ve assertion'lar DOM'daki değişikliği doğrudan görür, zaman içinde geriye dönüp her adımın anlık görüntüsünü incelemeye izin veren bir hata ayıklama deneyimi sunar. Getirdiği kısıt da aynı köktendir: Cypress uzun süre tek sekmeyle sınırlı kaldı, birden fazla origin arasında gezinmek özel bir komut gerektirir, yeni sekmede açılan pop-up'ları test etmek doğrudan desteklenmez ve dolandırılması gerekir.

Playwright farklı bir yol seçti: tarayıcıyı kendi protokolü üzerinden, ayrı bir süreçten, WebSocket üzerinden yönetir. Test kodu tarayıcının içinde değil dışında çalışır. Bu sayede birden fazla tarayıcı bağlamını (context) ve sekmeyi aynı testte eş zamanlı sürebilir, origin değiştirmek özel bir işlem gerektirmez, popup ve yeni sekme akışları doğal olarak çalışır. Chromium'un yanında Firefox ve WebKit için de kendi yamalı derlemelerini sağladığından üçü de birinci sınıf tarayıcı olarak test edilir. Dil tarafında da JavaScript/TypeScript'e ek olarak Python, Java ve .NET bağlayıcıları vardır; bu, testleri ayrı bir ekip ya da farklı bir dilde çalışan bir platform ekibi yazacaksa önemli bir ayrım noktasıdır.

Hangisi nerede kazanır

Saf frontend ekibi, tek sayfa uygulaması, JavaScript dışında bir dil kullanma ihtimali yok, hata ayıklarken adım adım geriye sarma deneyimi öncelikli: Cypress burada hâlâ güçlü bir seçenek. Zaman yolculuğu arayüzü ve komut günlüğü, bir testin neden kırıldığını anlamak için ekstra log basmaya gerek bırakmadan hızlı fikir verir.

Çok tarayıcılı gerçek doğrulama gerekiyorsa (özellikle Safari/WebKit davranışı önemliyse), testler CI'da paralel ve sayıya bölünerek (sharding) koşacaksa, ya da test yazımı farklı dillerde çalışan ekiplere yayılacaksa varsayılan seçim Playwright olmalı. Yeni başlayan bir proje için de aynı tavsiye geçerli: yerleşik test koşucusu, iz kaydedici (trace viewer) ve paralel çalıştırma desteği ek araç kurmadan geliyor, bu da bakım yükünü azaltıyor.

İkisi de güzel demek burada bir işe yaramaz: eğer proje çok dilli değilse ve Safari doğrulaması kritik değilse Cypress'in kurulumu daha hızlıdır; ama yeni bir proje sıfırdan başlıyorsa ve büyüme ihtimali varsa Playwright'ın esnekliği baştan seçilmeye değer, çünkü sonradan mimariyi değiştirmek (tek sekme varsayımı üzerine kurulmuş yüzlerce testi taşımak) pahalıdır.

Uçtan uca testte tekrar eden tuzaklar

Hangi aracı seçerseniz seçin, uçtan uca testler aynı sınıftan sorunlarla kırılır. Bunları bilmek framework seçiminden daha çok zaman kazandırır.

Sabit süreli bekleme, gerçek sinyali gizler. wait(5000) gibi bir komut, arkasındaki gerçek koşulu unutturur. O bekleme neden konmuştu diye sormak gerekir: çoğu zaman işlem bitince görünen gerçek sinyal bir modalın kapanması değil, bir bildirimin ekranda belirmesidir. Modal, arkadaki asenkron işlem daha sonuçlanmadan kapanabilir. Bekleme süresini kısaltıp koşula bağladığınızda, testin gerçekte neyi doğruladığı da netleşir; süre dolup da koşul sağlanmazsa test kendi hata mesajını versin, sessizce geçmesin.

Aşırı geniş seçiciler yanlış hata verir. Bir bildirim kutusunun CSS sınıfı hem gerçek toast'ta hem de sayfa içi (inline) bir uyarıda kullanılıyorsa, bu seçiciden tek eleman bekleyen bir assertion sayfada on tane eşleşme bulup strict mode ihlali fırlatabilir. Bu, ürünün bozuk olduğu anlamına gelmez; seçicinin gereğinden geniş olduğu anlamına gelir. Seçiciyi daraltmak ya da tekil varlık yerine sayıyı doğrudan ölçmek (elemanın kaçıncı örneği, kaç tane) daha sağlam bir kontrol verir.

Bir suitin ilk testi genelde farklı bir ortamda koşar. İlk çalıştırma; derleme, bağlantı havuzunun ısınması, önbelleğin dolması gibi testin konusuyla ilgisi olmayan sebeplerle başarısız olabilir. Bunu suitin geri kalanıyla karıştırmayın: ayrı bir ısınma adımı koyup ilk testin başarısızlığını rapora farklı işaretleyin, aksi halde her koşuda rastgele bir test flaky damgası yer.

Temiz tarayıcı oturumu, geliştiricinin gördüğünden farklı davranır. Bir ürün turu ya da onboarding katmanı yerel localStorage'da bu tur zaten görüldü bayrağına bakar. Geliştiricinin kendi tarayıcısında bu bayrak zaten var, CI'ın temiz oturumunda yok; tur katmanı gerçek butonun üstüne oturup tıklamayı yutar. Testin her sayfa geçişinden sonra böyle bir örtü olup olmadığını kontrol edip varsa kapatması gerekir.

CI'daki koşucu kodu tazelemezse eski kodu doğrular. Kalıcı bir checkout kullanan bir test ortamı, kod her değiştiğinde açıkça güncellenmezse önceki durumun anlık görüntüsünü koşturmaya devam eder. Bu en tehlikeli biçimde, bu hata bir daha çıkmasın diye eklenen bir regresyon testinde ortaya çıkar: test yeşil görünür ama aslında düzeltmeden önceki kodu ölçüyordur. Her koşudan önce ortamın gerçekten güncellendiğini doğrulamak, yeşil sonuca güvenmenin ön koşuludur.

Seçici disiplini: stile değil role bağlan

Yukarıdaki tuzakların çoğu aslında tek bir kök nedene çıkar: seçicinin uygulamanın görünümüne değil davranışına bağlanması gerekir. Bir CSS sınıfı, bir tasarım güncellemesinde isim değiştirebilir ya da başka bir bileşenle paylaşılabilir; ikisi de testi ürünle hiçbir ilgisi olmayan bir sebeple kırar. Rol tabanlı seçiciler (bir butonun erişilebilirlik rolü ve görünen metni, bir alanın etiketi) tasarımın değişmesine karşı çok daha dayanıklıdır, çünkü kullanıcı da o elemanı aynı yoldan bulur: gördüğü metinle. Test kimliği için özel bir öznitelik eklemek (data-testid benzeri) bir orta yoldur; stil değişse de kalır, ama testin gerçekten kullanıcı gibi davranıp davranmadığını ölçmez. İkisi arasında seçim proje büyüklüğüne göre değişir: küçük bir ekip için rol tabanlı seçiciler hem testi hem de erişilebilirliği aynı anda iyileştirir, büyük ve sık tasarım değişen bir üründe özel test kimlikleri daha öngörülebilir bir sözleşme sunar.

Ne zaman uçtan uca test yazmamalı

Uçtan uca testler en değerli olduğu yerde de en pahalıdır: gerçek tarayıcı, gerçek ağ, gerçek zamanlama. Bir iş kuralının doğru hesaplandığını doğrulamak için tarayıcıyı açıp formu doldurup butona basmak gerekmiyorsa, o kontrol birim ya da entegrasyon testine ait. Uçtan uca suit; kullanıcının gerçekten izlediği, birden fazla bileşenin bir araya geldiği kritik yolları (giriş, ödeme, kayıt tamamlama) doğrulamak için var. Bu ayrımı gözetmeyen bir ekip, her mantık değişikliğinde dakikalarca süren, sık sık flaky çıkan ve kimsenin güvenmediği bir suit biriktirir. Test piramidinin tepesi dar tutulmalı; genişlerse CI yavaşlar ve flaky testler gerçek hataları gürültünün içinde kaybettirir.