Cypress İpuçları #1: Ortam Tanımlamak ve Ortam Değişkenleri Kullanmak

Cypress serisindeki bir önceki yazı: Cypress İpuçları #0: Girizgâh

Motivasyon

Cypress hakkında girizgâhı önceki yazıda yaptığım için bu sefer doğrudan konuya gireceğim. Projelerin ölçeğine ve önemine göre, belirli operasyonları test etmek için yazdığımız uçtan uca test senaryolarını farklı ortamlarda koşturma ihtiyacı duyabiliyoruz.

Örnek

Somut örnek vermek gerekirse; Cypress web sitesinin üye girişi sürecini test eden bir senaryomuz olduğunu düşünelim. Kabaca, ilk olarak kullanıcı Cypress web sitesini açacak. Üye girişi bağlantısına tıklayacak. Daha sonra giriş yöntemini seçecek ve üyelik bilgilerini girerek giriş sürecini tamamlayacak.

Giriş süreçlerinde kimi geliştirmeler yapıldığını varsayalım. Geliştirici, geliştirmeler sonrasında her şeyin doğru çalıştığından emin olmak için üstteki senaryoyu geliştirme yaptığı bilgisayarda (development) test etmek isteyecek. Akabinde bu özelliği yayına çıkmadan evvel QA ekibi de kendi ortamında (testing/QA) test etmek isteyecek. Son olarak ise özellik yayımlandıktan sonra canlı ortamda (production) son kullanıcı testleri yapılacak.

Temsili ortamlar — Görsel: https://www.miamioh.edu/it-services/news/2017/08/dev-test-prod.html

Bu testler sırasında önceden yazılan senaryolarda ortama göre görsel bir değişiklik olmayacak. Kullanıcı üyelik bilgilerini girdikten sonra yine aynı butona basacak giriş yapabilmek için. Fakat test esnasında kullanılan veriler değişkenlik gösterecek. Cypress web uygulamasının geliştirme ortamındaki URL’i ile test ortamındaki URL’i farklı olacak. Keza test ortamındaki üyelik bilgileriyle canlı ortamdaki üyelik bilgileri de birbirinden farklı olacak.

Özetle, aynı test senaryolarını farklı ortamlarda farklı verilerle koşturmak için bir çözüme ihtiyacımız olacak. Bu noktada ortam değişkenleri imdadımıza yetişiyor.

Cypress ve DotEnv

Pratikte görmek için ilk olarak cypress ve ortam değişkenlerini dosyalar üzerinden yönetmemizi sağlayan dotenv paketlerini kuralım.

NPM bağımlılıklarının kurulması

Akabinde Cypress’in test runner ismini verdiği test arayüzünü aşağıdaki komutla başlatabiliriz.

Cypress runner’ın ilk açılışı

Fakat her defasında node_modules altından uzun uzadıya Cypress’e erişmek yerine package.json dosyasına bir script tanımlayabiliriz. Bu script’i tanımlarken env isminde bir argüman beklediğimizi ve gelen bu argümanı TEST_ENV ismindeki ortam değişkenine atayacağımızı belirtelim.

Bu sayede test arayüzünü ayağa kaldırırken aynı zamanda komut satırından alacağımız ortam bilgisini de daha sonra kullanmak üzere saklamış olduk.

package.json’da script tanımlama

Cypress, eklenti tanımlamalarını konvansiyon olarak plugins dizini altında topluyor. Ortam değişkeni dosyasının seçimini aşağıdaki dotenv yapılandırmasıyla plugins altında sağlayalım.

plugins/index.js

Burada yapılanı özetlemek gerekirse, test arayüzünü ayağa kaldırırken komut satırından bir argüman almış ve TEST_ENV değişkenine atamıştık. Bu yapılandırmada ise Node.js’in ortam değişkeni dosyası olarak .env.TEST_ENV ile argüman olarak belirttiğimiz ortama ait dosyayı dikkate almasını sağladık.

Ortam Değişkeni Dosyaları

Temsili olarak yine testlerimizi koşturacağımız üç farklı ortamımız olduğunu varsayalım. .env.development, .env.test ve .env.production ortam dosyalarını projenin ana dizinde oluşturalım ve içlerinde APP_URL isimli, uygulamanın açılacağı URL’i tutan değişkeni tanımlayalım.

.env.development
.env.test
.env.production

Örnek Test Yazmak

Yalnızca uygulamanın erişilebilir olup olmadığını kontrol edecek ilk test senaryomuzu yazalım. Test içerisindeki Cypress.env metodu, ilgili ortam dosyasındaki APP_URL değişkeninin değerini getirecek.

integration/open-app.test.js

Ortama Göre Testleri Koşturmak

Yukarıda tanımladığımız script yardımıyla Cypress test arayüzünü production ortam için çalıştıralım.

Test runner’ı ortama göre çalıştırmak

Açılan arayüzde proje içerisindeki tüm test senaryoları listelenecek.

Koşturulacak testin seçimi

İstersek spesifik olarak bir testi istersek de tüm testleri sırayla koşturabiliriz. Aynı zamanda bu aşamada testlerin koşturulacağı tarayıcı seçimini de yapmak mümkün.

Seçilen testin runner üzerinde koşturulması

Bu sayede ortam değişkeni dosyalarından aldığımız bilgilerle senaryo akışına dokunmadan testleri farklı ortamlarda koşacak hâle getirmiş olduk.

Son olarak ufak iki hatırlatma yapayım.

  • Ortam tanımı, Cypress arayüzü ayağa kaldırılmadan evvel yapıldığından ortam değişkenlerinde bir güncelleme yapıldığında test arayüzünün yeniden ayağa kaldırılması gerekmekte. Aksi takdirde değişiklikler senaryolara yansımayacaktır.
  • Örnek olması açısından ortam dosyalarını örnek repoya dahil ettim. Fakat gerçek hayat senaryolarında ortam dosyaları içerisinde hassas veriler (API key’ler, kredi kartı bilgileri vs.) tutulacağı için repoya dahil edilmezler. Repoya dahil edilecek .env.example dosyasında yalnızca değişken isimleri tutulur ki testlerin koşturulabilmesi için hangi verilere ihtiyaç duyulduğu anlaşılabilsin.

Sonuç

Ortamlarla çalışmak, Cypress kullanmanın ilk adımı olarak görülebilir. Uçtan uca testleri yazılabilecek ölçekteki projelerin neredeyse tamamı en azından ikinci bir ortama ihtiyaç duyar. O nedenle Cypress öğrenmeye buradan başlamak bana iyi bir pratik gibi geliyor.

Kaynaklar

Cypress serisindeki bir sonraki yazı: Cypress İpuçları #2: Iframe ile Çalışmak

--

--

Front-End Developer @Akbank — tugsanunlu.com

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store