Modern Test Otomasyon Araçları: Selenium, Cypress ve Playwright Kıyaslaması

Bir web projesini canlıya taşımadan önce en çok sorduğum soru şudur: bu formu, bu ödeme adımını, bu giriş ekranını her sürümde elle mi deneyeceğiz? Cevap hayırsa sıra test otomasyon araçları seçimine gelir. Bu yazıda Selenium, Cypress ve Playwright'ı yan yana koyuyor, kod örnekleriyle farklarını gösteriyor ve hangi ekip için hangisinin mantıklı olduğunu kendi saha tecrübemle anlatıyorum.

Test otomasyon araçları nedir ve Selenium, Cypress, Playwright arasındaki temel fark ne?

Test otomasyon araçları, bir tarayıcıyı kod aracılığıyla yöneterek kullanıcının tıklama, yazma ve gezinme adımlarını tekrar eden yazılımlardır. Temel fark mimaridedir: Selenium tarayıcıyı W3C WebDriver protokolüyle dışarıdan sürer, Cypress testi tarayıcının içinde çalıştırır, Playwright ise tarayıcıyla doğrudan kendi protokolü üzerinden konuşur.

Bu üç yaklaşım kağıt üzerinde küçük bir ayrıntı gibi görünür. Ancak hız, kararlılık, desteklenen diller ve çoklu sekme gibi konularda gündelik hayatınızı doğrudan belirler. Örneğin Cypress'in yalnızca JavaScript desteklemesi, bu mimari tercihin doğal sonucudur. Dolayısıyla araç seçerken önce mimariyi anlamak, sonra özellik listesine bakmak daha sağlıklı sonuç verir.

Rol tarafını, yani bir test otomasyon mühendisinin günlük işini ve STLC aşamalarını ayrı bir yazıda ele alıyorum. Burada yalnız araçlara odaklanıyorum. Eğer işin kariyer kısmını merak ediyorsanız önce o yazıya, sonra bu karşılaştırmaya dönmenizi öneririm.

Neden hâlâ üç araç konuşuyoruz, tek bir kazanan yok mu?

Test otomasyon araçları arasında tek bir kazanan yok, çünkü üç araç farklı sorunları çözmek için doğdu. Selenium 2000'lerin ortasında tarayıcı otomasyonunun kendisini mümkün kıldı ve bugün W3C tarafından standartlaştırılmış WebDriver protokolünün arkasındaki projedir. Cypress, ön yüz geliştiricisinin testi rahatça yazıp anında görmesi fikriyle çıktı. Playwright ise Microsoft bünyesinde, modern tarayıcıların hepsini tek bir API ile yönetme hedefiyle geldi.

Sahada gördüğüm tablo şu: kurumsal ve çok dilli ekiplerde Selenium hâlâ güçlü, ön yüz ağırlıklı JavaScript ekiplerinde Cypress seviliyor, yeni başlayan projelerde ise Playwright giderek varsayılan tercih haline geliyor. Bu gözlem saha tecrübesidir, garanti değildir. Yani kendi ekibinizin dilini, altyapısını ve bütçesini bu tabloya koymadan karar vermeyin.

Üstelik bu araçlar birbirinin yerini tamamen tutmaz. Bazı ekipler bileşen testleri için Cypress, uçtan uca akışlar için Playwright kullanır. Önemli olan, her testin neden var olduğunu bilmek ve bakımını yapabileceğiniz kadar araç tutmaktır.

Selenium nasıl çalışır ve hangi durumlarda hâlâ en mantıklı seçimdir?

Selenium WebDriver, test kodunuz ile tarayıcı arasında bir sürücü katmanı kullanır. Kodunuz komutu sürücüye gönderir, sürücü de tarayıcıya iletir. Bu yapı W3C WebDriver standardına dayanır; dolayısıyla Chrome, Firefox, Edge ve Safari'yi aynı mantıkla sürebilirsiniz. Selenium 4.6 ile gelen Selenium Manager, sürücü indirme derdini de büyük ölçüde ortadan kaldırdı.

Selenium'un en büyük gücü dil desteğidir. Resmi bağlamalar Java, Python, C#, Ruby ve JavaScript için mevcuttur. Bu nedenle backend ekibiniz Java ile çalışıyorsa, test kodunu aynı dilde ve aynı araç zinciriyle yazmak büyük kolaylık sağlar. Selenium Grid ise testleri birden fazla makineye ve tarayıcıya dağıtmanızı sağlar.

• Mantıklı olduğu durum: Java veya C# ağırlıklı kurumsal ekip, mevcut büyük test takımı, gerçek Safari ya da eski tarayıcı ihtiyacı.
• Dikkat isteyen durum: bekleme stratejisini siz kurarsınız; açık bekleme yazmazsanız kararsız testler çoğalır.
• Gözden kaçan nokta: Selenium bir test koşucusu değildir; JUnit, TestNG veya pytest gibi bir çatıyla birlikte düşünmeniz gerekir.

Cypress'i diğerlerinden ayıran mimari neden önemli?

Cypress testleri tarayıcının içinde, uygulamanızla aynı döngüde çalıştırır. Bu sayede DOM'a, ağ isteklerine ve uygulama durumuna çok yakın durursunuz. Test çalışırken her adımı görsel olarak izleyebilir, geçmiş adımlara dönüp o anki ekranı inceleyebilirsiniz. Geliştirici deneyimi açısından bu, Cypress'in en sevilen tarafıdır.

Öte yandan aynı mimari bazı kalıcı sınırlar getirir. Cypress'in kendi dokümantasyonundaki trade-offs sayfası bunları açıkça yazar: test kodu yalnızca JavaScript veya TypeScript olabilir, aynı anda birden fazla tarayıcıyı kontrol edemezsiniz ve her test tek bir üst alan adına bağlıdır. Farklı bir kökene geçmek için cy.origin() komutunu kullanmanız gerekir.

Kısacası Cypress, tek sayfa uygulaması geliştiren ve testini kendisi yazan ön yüz ekipleri için çok rahat bir ortamdır. Ancak ödeme sağlayıcısına yönlendirme, çoklu sekme ya da iki kullanıcının aynı anda etkileştiği senaryolar sizin için kritikse bu sınırları baştan hesaba katmalısınız.

Playwright neyi farklı yapıyor ve neden bu kadar hızlı yayıldı?

Playwright, Chromium, Firefox ve WebKit'i tek bir API üzerinden yönetir. Resmi dokümantasyona göre Windows, Linux ve macOS üzerinde, yerelde veya CI ortamında, başlıksız ya da görünür modda çalışır ve mobil emülasyonu yerleşik olarak sunar. WebKit desteği, Safari davranışını Mac olmadan da yaklaşık olarak test edebilmeniz anlamına gelir.

Playwright'ı hızlı yayan asıl şey ise günlük kullanımdaki pratiklerdir. Otomatik bekleme sayesinde bir elemana tıklamadan önce onun görünür ve etkin olmasını kendisi bekler. Trace Viewer ile başarısız bir testin her adımını, ağ trafiğini ve ekran görüntülerini sonradan inceleyebilirsiniz. Codegen aracı ise tarayıcıda yaptığınız tıklamaları test koduna çevirir.

• Resmi dil desteği: JavaScript/TypeScript, Python, Java ve .NET.
• Yerleşik paralel çalıştırma ve HTML rapor.
• Birden fazla sekme, pencere ve tarayıcı bağlamını aynı testte yönetebilme.
• UI Mode ile izleme modu ve zamanda geriye dönük hata ayıklama.

Bununla birlikte Playwright'ın ekosistemi Selenium kadar eski değildir. Dolayısıyla çok özel bir kurumsal entegrasyon arıyorsanız, hazır eklenti bulma ihtimaliniz Selenium tarafında hâlâ daha yüksek olabilir.

Test otomasyon araçları karşılaştırma tablosunda nasıl görünür?

Aşağıdaki tablo, üç aracın resmi dokümantasyonlarındaki bilgilere dayanır. Sürüm ayrıntıları zamanla değişebileceği için karar vermeden önce ilgili sayfayı bir kez daha kontrol etmenizi öneririm.

Test otomasyon araçları tablosunu okurken tek bir satıra takılmayın. Örneğin paralel çalışma sizin için önemsizse, Cypress'in bu konudaki farkı kararınızı değiştirmemelidir.

Aynı giriş testi üç araçta nasıl yazılır?

Farkı en iyi aynı senaryoyla görürsünüz. Senaryomuz basit: giriş sayfasını aç, e-posta ve şifre yaz, butona bas, panel başlığının göründüğünü doğrula. Aşağıdaki örnekler kavramı göstermek içindir; seçici adlarını kendi projenize göre değiştirmeniz gerekir.

Selenium (Python): driver.get(URL) ile sayfayı açarsınız. Ardından WebDriverWait(driver, 10).until(EC.visibility_of_element_located((By.ID, "email"))) ile alanı beklersiniz. Sonra send_keys ile değerleri yazar, click ile butona basarsınız. Son adımda başlığın metnini assert ile kontrol edersiniz.

Cypress (JavaScript): cy.visit('/giris') ile başlarsınız. Ardından cy.get('#email').type(eposta), cy.get('#sifre').type(sifre) ve cy.contains('Giriş yap').click() satırları gelir. Kontrol için cy.contains('h1', 'Panel').should('be.visible') yeterlidir; bekleme yazmazsınız.

Playwright (TypeScript): await page.goto('/giris') ile açarsınız. Sonra await page.getByLabel('E-posta').fill(eposta) ve await page.getByRole('button', { name: 'Giriş yap' }).click() gelir. Doğrulama için await expect(page.getByRole('heading', { name: 'Panel' })).toBeVisible() kullanırsınız.

Gördüğünüz gibi Selenium'da beklemeyi siz yönetirsiniz, diğer ikisinde araç üstlenir. Üstelik Playwright'ın rol ve etiket tabanlı seçicileri, testi erişilebilirlik yapısına bağlar; bu da tasarım değiştiğinde kırılmayı azaltır.

Kendi projelerimde kararsız testleri ayrı bir listede tutarım. Bir test üst üste iki kez sebepsiz kalırsa listeye girer ve o hafta mutlaka kök nedeni aranır. Bu küçük disiplin, ekibin test sonuçlarına güvenini korur; çünkü sürekli yeniden çalıştırılan bir takım bir süre sonra kimsenin ciddiye almadığı bir gürültüye dönüşür.

Kararsız (flaky) testler hangi araçta daha az görülür?

Kararsız test, kodda değişiklik olmadığı halde bazen geçip bazen kalan testtir. Sahada gördüğüm kararsızlığın büyük kısmı araçtan değil, zamanlama varsayımlarından kaynaklanır. Sabit süre bekleyen, animasyonu hesaba katmayan ya da test verisini paylaşan testler hangi araçta yazılırsa yazılsın sorun çıkarır.

Bununla birlikte araç farkı gerçektir. Cypress ve Playwright'taki otomatik bekleme, Selenium'da elle yazmanız gereken pek çok beklemeyi ortadan kaldırır. Dolayısıyla Selenium'la çalışan ekiplerde kararsızlık daha sık, ama çoğunlukla disiplinle çözülebilir bir sorun olarak karşıma çıkıyor. Bu gözlem saha tecrübesidir, garanti değildir.

1. Sabit uyku komutu yerine koşula bağlı bekleme kullanın.
2. Her test kendi verisini oluştursun ve kendi verisini temizlesin.
3. CSS sınıfı yerine rol, etiket veya test kimliği gibi kararlı seçiciler seçin.
4. Dış servisleri, özellikle ödeme ve e-posta adımlarını, mümkünse taklit edin.
5. Kararsız testi susturmak yerine karantinaya alın ve kök nedenini bulun.

Ölçüm yaparken yalnızca toplam süreye bakmayın. Bir testin ilk çalıştırmada ne kadar sürdüğü, önbellekli ikinci çalıştırmada ne kadar sürdüğü ve başarısız olduğunda hatayı bulmanın kaç dakikanızı aldığı da önemlidir. Bence son kalem çoğu zaman en belirleyicisidir, çünkü ekibin asıl zamanı hata ayıklamada gider.

Hız ve CI/CD entegrasyonunda hangisi öne çıkar?

Hız konusunda kesin bir rakam vermeyeceğim, çünkü sonuç uygulamanıza, test sayınıza ve makinenize göre çok değişir. Kaynağı belirsiz "şu araç yüzde şu kadar hızlı" iddialarına da temkinli yaklaşmanızı öneririm. Bunun yerine kendi projenizde aynı beş testi üç araçla yazıp CI üzerinde ölçmek en dürüst yöntemdir.

Entegrasyon tarafında üçü de GitHub Actions, GitLab CI ve Jenkins gibi ortamlarda çalışır. Ancak yaklaşımları farklıdır. Playwright kurulum sihirbazında bir GitHub Actions dosyasını hazır olarak önerir ve paralel çalışmayı yerleşik sunar. Cypress'te paralelleştirme ve kayıt paneli için çoğu ekip ücretli bulut hizmetine yönelir. Selenium'da ise ölçeklemeyi Grid veya bir bulut sağlayıcısıyla siz kurarsınız.

Özetle küçük bir ekipseniz ve ek maliyet istemiyorsanız, Playwright'ın yerleşik paralel çalışması pratik bir avantajdır. Büyük bir kurumsal altyapınız varsa Selenium Grid'i zaten biliyor olabilirsiniz; o durumda geçiş maliyeti avantajı silebilir.

Örneğin kurumsal bir B2B sitesinde ziyaretçilerin çoğu masaüstü Chrome ve Edge kullanıyorsa, geniş tarayıcı matrisi için harcanan dakikalar gereksiz olabilir. Bu yüzden kararı varsayımla değil, kendi analitik verinizle verin.

Hangi tarayıcıları gerçekten test etmeniz gerekiyor?

Araç seçiminden önce bu soruyu cevaplamanızı öneririm. Analitik verinizde kullanıcılarınızın hangi tarayıcı ve cihazlardan geldiğine bakın. Eğer ziyaretçilerinizin önemli kısmı iPhone kullanıyorsa, Safari davranışı sizin için kritik demektir. Bu durumda gerçek Safari için Selenium, yaklaşık kontrol için Playwright'ın WebKit desteği öne çıkar.

Ayrıca mobil görünümü test etmek ile gerçek mobil cihazı test etmek aynı şey değildir. Playwright'ın mobil emülasyonu ekran boyutunu, dokunma olaylarını ve kullanıcı ajanını taklit eder; ancak gerçek cihazdaki performansı ve bazı tarayıcı tuhaflıklarını birebir yansıtmaz. Mobil taraftaki temel kontroller için mobil uyumluluk testi rehberime de göz atabilirsiniz.

Kısacası her tarayıcıyı her testte koşmak zorunda değilsiniz. Kritik akışları geniş tarayıcı matrisinde, geri kalanları tek tarayıcıda koşmak hem süreyi hem de maliyeti dengeler.

Test otomasyon araçları performans ve SEO testinin yerini tutar mı?

Tutmaz. Bu araçlar işlevsel doğruluğu ölçer: buton çalışıyor mu, form gönderiliyor mu, hata mesajı çıkıyor mu. Sayfa hızı, Core Web Vitals ve SEO sinyalleri ise ayrı araçların işidir. Cypress bile dokümantasyonunda kendini genel amaçlı bir otomasyon ya da performans test aracı olarak konumlamadığını açıkça belirtir.

Bununla birlikte ikisini birleştirebilirsiniz. Örneğin Playwright ile giriş yaptıktan sonra korumalı bir sayfada Lighthouse çalıştırmak mümkündür. Lighthouse'un kendisini nasıl okuduğumu Lighthouse ile performans testi yazımda anlattım. Hızın sıralamaya etkisi için de site hızı ve SEO ilişkisi yazısına bakabilirsiniz.

Benim pratikteki kuralım basit: işlevsel test kırmızıysa yayın durur, performans skoru düştüyse uyarı üretir ama yayını otomatik durdurmaz. Böylece ekip her küçük dalgalanmada panik yapmaz.

Canlıya çıkış öncesi test sürecinde bu araçların yeri nerede?

Bir web sitesini yayına almadan önce yaptığım kontroller geniş bir listedir: içerik, yönlendirmeler, form bildirimleri, izleme kodları, hız ve mobil görünüm. Bu listenin tamamını otomasyona dökmek ne gerekli ne de verimlidir. Otomasyonu, her sürümde tekrar eden ve bozulduğunda para kaybettiren akışlara ayırırım.

• İletişim ve teklif formunun gönderilmesi ve teşekkür sayfasına ulaşılması.
• Sepete ekleme, ödeme adımına geçiş ve sipariş özeti.
• Üye girişi, şifre sıfırlama ve oturum kapatma.
• Dil değiştirme ve doğru dil sayfasına yönlendirme.
• Kritik sayfaların 200 durum kodu dönmesi ve eski adreslerin doğru yönlenmesi.

Yönlendirmeleri tek tek kontrol etmek için yönlendirme denetleyici aracını hızlı bir ön kontrol olarak kullanabilirsiniz. Site taşıma gibi büyük değişikliklerde ise otomasyon testleri site taşıma kontrol listesinin yanında çalışmalıdır.

Ekibinizin diline ve becerisine göre nasıl seçim yaparsınız?

Test otomasyon araçları arasında seçim yaparken ilk sorum her zaman şudur: testleri kim yazacak ve kim bakımını yapacak? Test kodu da üretim kodu gibi bakım ister. Bu yüzden ekibin rahat olduğu dilde yazmak, özellik listesinden daha belirleyicidir.

• Ekip JavaScript/TypeScript ile ön yüz geliştiriyor: Cypress veya Playwright. Çoklu sekme ve farklı kökenler önemliyse Playwright.
• Ekip Java veya C# ağırlıklı: mevcut altyapı varsa Selenium; sıfırdan başlıyorsanız Playwright'ın Java veya .NET sürümü de değerlendirilmeye değer.
• Ekip Python kullanıyor: Selenium veya Playwright; Cypress bu durumda uygun değildir.
• Ayrı bir QA ekibi var ve geliştiricilerle ortak dil yok: QA ekibinin güçlü olduğu dili seçin.

Ayrıca işe alım gerçeğini de düşünün. Seçtiğiniz aracı bilen kişiyi bulmak ne kadar kolay? Bu konuda yerel iş ilanlarına bakmak, herhangi bir popülerlik anketinden daha gerçekçi bir fikir verir.

Selenium'dan Playwright'a geçmek mantıklı mı?

Her zaman değil. Çalışan, kararlı ve ekibin sahiplendiği bir Selenium takımını yalnızca yeni araç popüler diye taşımak, çoğu zaman aylar süren bir yeniden yazma projesine dönüşür. Bu süreçte yeni özellik testi yazılmaz, ekip moral kaybeder. Dolayısıyla geçiş kararını bir sorunun çözümü olarak vermelisiniz, moda olarak değil.

Geçişi haklı kılan somut sinyaller şunlardır: kararsız test oranı ekibi yavaşlatıyor, WebKit veya çoklu sekme ihtiyacı doğdu, bakım yükü yeni test yazmayı engelliyor. Bu durumda büyük patlama yerine kademeli yol öneririm: yeni testleri Playwright'ta yazın, en sık kırılan eski testleri önce taşıyın, geri kalanı doğal ömrü dolana kadar yerinde bırakın.

Cypress'ten Playwright'a geçiş de benzer mantıkla ilerler. Üstelik ikisi de JavaScript tabanlı olduğu için test verisi yardımcılarını ve sayfa nesnelerini büyük ölçüde koruyabilirsiniz.

Ayrıca testlerin nerede koştuğu da bir maliyet kararıdır. Her commit için tüm tarayıcı matrisini koşmak yerine, birleştirme isteğinde tek tarayıcı, ana dala birleştirmede tam matris koşmak dengeli bir yol olur. Böylece geri bildirim hızlı kalır, fatura da kontrol altında olur.

Maliyet tarafında nelere dikkat etmelisiniz?

Bu üç test otomasyon aracının çekirdeği de açık kaynaklıdır ve lisans ücreti istemez. Ancak toplam maliyet lisanstan ibaret değildir. Asıl maliyet, testleri yazan ve bakımını yapan insan zamanı ile testlerin koştuğu altyapıdır.

• İnsan zamanı: kararsız testlerle uğraşmak, en pahalı gizli kalemdir.
• CI dakikaları: tarayıcı matrisi büyüdükçe süre ve fatura büyür.
• Bulut hizmetleri: Cypress Cloud gibi kayıt ve paralelleştirme hizmetleri veya gerçek cihaz bulutları ek ücret getirebilir.
• Eğitim: ekip yeni bir araca geçiyorsa öğrenme eğrisini takvime koyun.

Bir web projesinin toplam bütçesini planlarken test otomasyonunu ayrı bir kalem olarak düşünmenizi öneririm. Web tasarım projelerimde bu kalemi baştan konuşuyoruz; çünkü sonradan eklenen test genellikle daha pahalıya mal olur.

Test otomasyonu dönüşüm ve reklam bütçesini nasıl korur?

Bu yazının teknik görünen konusunun pazarlama tarafında çok somut bir karşılığı var. Reklamdan gelen ziyaretçi bozuk bir forma düşerse, o tıklamanın parasını ödersiniz ama dönüşüm alamazsınız. Üstelik dönüşüm etiketi de tetiklenmediği için kampanya optimizasyonu yanlış veriyle çalışır.

Bu nedenle Google Ads yönetimi yaptığım projelerde en kritik dönüşüm akışının her sürümden sonra otomatik olarak denenmesini isterim. Basit bir Playwright testi formu doldurur, teşekkür sayfasına ulaşıldığını ve dönüşüm isteğinin tarayıcıdan çıktığını doğrular. Böylece bozuk formu bir hafta sonra rapordan değil, aynı gün test çıktısından öğrenirsiniz.

Ayrıca UTM parametrelerinin yönlendirmelerde kaybolmadığını test etmek de faydalıdır. Test bağlantılarını UTM oluşturucu ile hazırlayıp akış sonunda parametrelerin korunup korunmadığını kontrol edebilirsiniz. Hangi hedefi izlemeniz gerektiğini netleştirmek için dönüşüm hedefi belirleme yazıma bakabilirsiniz.

Yapay zeka destekli test özellikleri seçimi değiştiriyor mu?

Son dönemde üç aracın çevresinde de yapay zeka destekli özellikler çıktı: kod üreten asistanlar, kırılan seçiciyi kendisi onaran eklentiler ve doğal dilden test taslağı çıkaran araçlar. Bunlar başlangıç hızını artırabilir. Ancak benim deneyimim, üretilen testin gözden geçirilmeden takıma girmesinin kararsızlığı artırdığı yönünde.

Dolayısıyla yapay zekayı karar kriteri değil, yardımcı olarak görmenizi öneririm. Temel mimari, dil desteği ve hata ayıklama kalitesi hâlâ belirleyicidir. Üstelik kendi kendini onaran seçiciler bazen gerçek bir hatayı da "onarıp" gizleyebilir; bu da testin varlık amacına ters düşer.

Kısacası iyi bir test hâlâ net bir iş kuralını doğrulayan, okunabilir ve tek sorumluluğu olan koddur. Hangi araçla ya da hangi asistanla yazdığınız bunu değiştirmez.

Sayfa nesnesi modeli üç araçta nasıl kurulur?

Sayfa nesnesi modeli, her ekranın seçicilerini ve eylemlerini tek bir sınıfta toplamanızı sağlayan bir düzendir. Böylece giriş butonunun seçicisi değiştiğinde yüz testi değil, tek bir dosyayı güncellersiniz. Bu düzen araçtan bağımsızdır; ancak her araç onu farklı bir rahatlıkla taşır.

Selenium tarafında sayfa nesnesi neredeyse zorunludur, çünkü açık beklemeleri ve seçicileri bir yerde toplamazsanız test kodu hızla dağılır. Java ekiplerinde bu yapı zaten gelenek haline gelmiştir. Playwright'ta da aynı mantıkla sınıflar kurarsınız; üstelik fixture sistemi, hazır giriş yapmış bir sayfayı testlere enjekte etmenizi kolaylaştırır.

Cypress ise kendi dokümantasyonunda sayfa nesnesi yerine özel komutları ve uygulama eylemlerini öne çıkarır. Örneğin giriş adımını her testte arayüzden yapmak yerine cy.request ile arka planda oturum açıp doğrudan panele gitmeyi önerir. Bu yaklaşım testleri hızlandırır ama arayüz üzerinden girişi ayrı bir testte mutlaka korumanız gerekir.

Benim pratiğim şu: hangi aracı seçerseniz seçin, seçicileri tek yerde tutun ve testin kendisini iş diliyle yazın. Yani test okunduğunda "kullanıcı teklif formunu gönderir" gibi anlaşılır bir cümle çıkmalıdır.

Bileşen testi ve API testi desteği nasıl farklılaşır?

Uçtan uca testler değerlidir ama yavaştır. Bu yüzden iyi bir test stratejisi, işin çoğunu daha hızlı katmanlara taşır. Burada üç araç arasında belirgin farklar vardır ve seçimi etkileyebilir.

Cypress, React, Vue, Angular ve Svelte gibi çatılarda bileşen testini resmi olarak destekler. Bir butonu ya da formu, tüm uygulamayı ayağa kaldırmadan gerçek tarayıcıda test edersiniz. Playwright da bileşen testini sunar ancak dokümantasyonunda bu özelliği deneysel olarak etiketler. Selenium'un ise bileşen testi gibi bir hedefi yoktur; o, tarayıcıyı sürmeye odaklanır.

API testi tarafında Cypress cy.request, Playwright ise request fixture'ı ile HTTP isteklerini doğrudan atmanıza izin verir. Bu sayede test verisini arayüzden değil API'den hazırlarsınız ve testler belirgin biçimde kısalır. Selenium'da bunun için dilinizin kendi HTTP kütüphanesini ayrıca kullanırsınız; örneğin Python'da requests.

Kısacası ön yüz ekibiniz bileşen testine önem veriyorsa Cypress bu konuda en olgun seçenek. Uçtan uca ve API testini tek araçta toplamak istiyorsanız Playwright daha dengeli bir paket sunar.

Sıfırdan başlayan bir ekip için benim önerim ne?

Hiçbir mirası olmayan, yeni bir web projesine başlayan bir ekipseniz benim varsayılan önerim Playwright'tır. Gerekçem çok tarayıcı desteği, birden fazla dil seçeneği, yerleşik paralel çalışma ve Trace Viewer'ın hata ayıklamada kazandırdığı zamandır. Bu bir tavsiyedir, evrensel bir kural değildir.

Eğer ekibiniz tamamen JavaScript ile çalışıyor, uygulamanız tek kökende kalıyor ve geliştiriciler testin görsel akışını izlemeyi seviyorsa Cypress de mükemmel bir seçimdir. Öte yandan büyük bir Java altyapınız ve yıllara yayılmış bir Selenium takımınız varsa, onu korumak çoğu zaman en ekonomik karardır.

1. Kullanıcılarınızın tarayıcı ve cihaz dağılımını çıkarın.
2. Ekibin rahat olduğu dili ve CI altyapısını not edin.
3. En kritik üç akışı seçin ve aday iki araçta prototip yazın.
4. Kararsızlık, süre ve hata ayıklama kolaylığını iki hafta gözlemleyin.
5. Kararı yazıya dökün ve yeni testleri yalnızca seçilen araçla yazın.

Bu tür teknik kararları web projesinin tamamıyla birlikte ele almak isterseniz iletişim sayfasından bana ulaşabilirsiniz.