Cypress ile web arayüzü testi yazma rehberi

Cypress nedir ve diğer araçlardan farkı nedir?

Cypress, web uygulamalarının arayüzünü gerçek bir tarayıcıda otomatik olarak sınayan bir test aracıdır. Testlerin kendisi JavaScript ya da TypeScript ile yazılır ve uygulamanın bulunduğu tarayıcı döngüsünün içinde çalışır. Bu mimari, aracın uygulamanın durumunu, ağ trafiğini ve DOM'u doğrudan görmesini sağlar.

Günlük kullanımda öne çıkan özellikleri şunlardır: komutlar otomatik olarak yeniden denenir ve beklenir (bir element görünene kadar kendiliğinden bekler), etkileşimli çalıştırıcıda her adımın o anki görüntüsüne geri dönülebilir, ağ isteklerini kolayca yakalayıp taklit edebilirsiniz. Önemli bir sınır, mimarisinden doğar: Cypress testleri tarayıcı içinde çalıştığı için bazı çoklu sekme ya da çoklu pencere senaryolarında kısıtlar vardır. Bu tür ihtiyaçlarda diğer araçlar düşünülebilir.

Kurulum ve ilk test

Cypress, geliştirme bağımlılığı olarak projeye eklenir ve ilk açılışta örnek yapılandırma ile klasör düzenini üretir. Testler belirli bir klasörde, ayrı dosyalar hâlinde tutulur. Etkileşimli modda tarayıcıyı açıp testleri izleyerek, komut satırı modunda ise başsız (görünür arayüz olmadan) çalıştırabilirsiniz.

Bir testin iskeleti Mocha tarzındadır: describe ile gruplar, it ile tek bir senaryo tanımlanır. Örneğin bir giriş senaryosu şöyle akar: adrese git (cy.visit), kullanıcı adı ve parola alanlarını bul ve doldur, gönder düğmesine tıkla, sonra yönlendirme adresinin ve karşılama mesajının göründüğünü doğrula. İlk testi küçük tutun, bir kullanıcı akışını başından sonuna doğrulayan tek bir senaryo yazın. Testin her adımı arayüzde izlenebildiği için neyin başarısız olduğunu görmek kolaydır.

Element seçme ve etkileşim: kırılgan olmayan seçiciler

Arayüz testinin en sık kırıldığı yer, elementi bulma biçimidir. cy.get ile CSS seçiciyle, cy.contains ile görünen metne göre element bulabilirsiniz. Bulduğunuz elemente tıklama, yazma, seçim yapma gibi etkileşimler uygulanır ve ardından should ile durum doğrulanır.

Kırılgan test yazmamanın ilkesi şudur: seçici, tasarım değiştiğinde bozulmayacak bir özelliğe dayanmalı. Sınıf adları ve sıra numarası gibi stil ya da düzenle ilgili özellikler sık değişir. Çözüm, test için ayrılmış özel bir öznitelik (örneğin data-cy ya da benzeri) eklemek ve seçicileri ona bağlamaktır. Böylece tasarımcı bir sınıfı yeniden adlandırdığında test bozulmaz. Bekleme konusunda sabit bir süre beklemek (sabit bekleme) yerine, Cypress'in otomatik yeniden denemesini ve durum doğrulamasını kullanın; sabit beklemeler testi hem yavaşlatır hem kararsız yapar.

Ağ isteklerine müdahale ve API taklidi

Arayüz testi, arka yüzle konuşan istekleri nasıl ele aldığınıza göre ayrı yaklaşımlara bölünür. Gerçek arka yüze karşı çalışmak, uçtan uca güven verir ama yavaş ve veriye bağımlıdır. Ağ isteklerini taklit etmek ise hızlı, deterministik ve hata durumlarını simüle etmeye uygundur.

Cypress'te cy.intercept ile belirli bir isteği yakalar, yanıtını sabit bir veriyle değiştirir ya da isteği izleyip tamamlanmasını beklersiniz. Bu sayede örneğin sunucu hatası dönen bir istek için arayüzün hata mesajını doğru gösterip göstermediğini, yavaş bir yanıtta yükleme göstergesinin çıkıp çıkmadığını ya da boş bir listede boş durum ekranının görüldüğünü sınayabilirsiniz; bu durumları gerçek arka yüzde üretmek zordur. Taklit yanıtları fixture dosyalarında tutarsanız testler okunabilir kalır. Yine de taklidi ölçülü kullanın: tamamı taklitli testler gerçek entegrasyonu sınamaz, bu yüzden kritik akışlar için gerçek arka yüze karşı birkaç uçtan uca test bırakın.

Komponent testi

Cypress yalnızca tam sayfa akışlarını değil, tek tek arayüz bileşenlerini de sınayabilir. Komponent testinde bileşen, tam uygulama olmadan, gerçek tarayıcıda izole olarak çizilir ve girdilerle (özellikler, durumlar) birlikte sınanır. Bu, birim testinin hızıyla gerçek tarayıcı doğruluğu arasında bir orta nokta sunar.

Bir bileşende özelliklere farklı değerler vererek davranışı doğrulamak, olay işleyicilerinin çağrıldığını izlemek ve görsel durumları (hata, yükleniyor, boş) kontrol etmek komponent testinin tipik işleridir. Tam sayfa testlerine göre çok daha hızlı çalışır ve başarısızlık nedenini doğrudan bileşene indirger. Sağlıklı bir yaklaşım, bileşen düzeyinde ayrıntılı durum testleri ve sayfa düzeyinde az sayıda kritik akış testi bulundurmaktır.

Özel komutlar, fixture ve CI hattı

Testler çoğalınca tekrar eden adımlar kaçınılmaz olur; giriş yapmak bunun klasik örneğidir. Özel komutlar (Cypress.Commands.add) bu adımı bir kez tanımlayıp tüm testlerde tek satırla kullanmanızı sağlar. Giriş gibi pahalı adımı arayüz üzerinden her testte yapmak yerine, oturumu doğrudan API çağrısıyla kurup önbelleğe almak testleri hızlandırır. Fixture dosyaları, test verilerini kodun dışında, yeniden kullanılabilir biçimde tutar. Eklentiler ise çatıyı raporlama, görsel karşılaştırma gibi ihtiyaçlarla genişletir.

Testlerin asıl değeri sürekli entegrasyon hattında ortaya çıkar. Hatta uygulama ayağa kaldırılır, testler başsız modda çalışır, başarısızlıkta ekran görüntüsü ve video kaydı çıktı olarak saklanır ve sonuçlar raporlanır. Test sonuçlarını toplayan ve paralel çalıştırmayı kolaylaştıran Cypress Cloud gibi hizmetler de vardır. Kararsız testleri izleyip hızla düzeltmek, paketin güvenilirliğini korur.

Sık yapılan hatalar ve öğrenme yolu

• Sınıf adlarına dayalı seçiciler: Tasarım değişince tüm testler kırılır.
• Sabit bekleme eklemek: Yavaş ve kararsız hâle getirir; durum doğrulamasına güvenin.
• Her şeyi arayüzden yapmak: Giriş ve veri hazırlığını API ile kurun.
• Testleri birbirine bağımlı yazmak: Her test kendi durumunu hazırlamalıdır.
• Çok fazla uçtan uca test: Yavaş ve bakımı zor olur; piramidin tabanını birim ve bileşen testleriyle doldurun.
• Başarısızlığı yeniden denemeyle gizlemek: Kök nedeni bulun.

Öğrenme sırası için şu yol uygundur: önce tek bir sayfada basit akış, sonra seçici stratejisi ve otomatik yeniden deneme mantığı, ardından ağ isteği taklidi, özel komutlar ve fixture, en son bileşen testi ve CI hattı. Gerçek bir uygulamanın giriş ve sepet gibi kritik akışlarını sınamak, en çabuk öğreten alıştırmadır.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Cypress ile UI Test Otomasyonu programının modülleri Cypress Mimarisi ve Kurulum, Element Sorgulama ve Etkileşim, Ağ İsteği Müdahale ve API Stubbing, Cypress Komponent Testi, Custom Komutlar, Eklentiler ve Fixture ile CI/CD, Raporlama ve Cypress Cloud başlıklarını taşır; bu sayfadaki bölümlerin her biri bir modül başlığına denk düşer.