React Uygulamalarında TDD

🚦Unit Test ≠ TDD!

TDD konusu geçtiğinde genelde şu sözü duyarız “Unit Test yazıyoruz”. Unit Test her ne kadar TDD’nin temelini oluştursa da TDD’nin tamamını oluşturmamaktadır. Yani sadece Unit Test yazarak TDD yapmış olmazsınız.

Neden Test Edilebilir Kodlar Yazmalıyız?

Test-Driven geliştirmenin temel kurallarından bir tanesi test edilebilir kod yazmaktır. Test-First ilerlediğinizde yazdığınız kod tamamen test edilebilir bir koda dönüşüyor. Ancak gerçek hayatta test-first ilerlemek çok gerçekçi bir senaryo olmayabiliyor. O nedenle ileride test yazmak istediğinizde kodunuzda refactor yapmanız gerekiyor. Testin önemini kavramaya başladıktan sonra en baştan test edilebilirliği düşünerek kod yazmanın olası zaman kayıplarının önüne geçtiğini anlayabiliyorsunuz.

Neden Modüler Uygulamalar Geliştirmeliyiz?

Modüler uygulamalar test edilebilirliğin daha kolay olduğu uygulamalardır. Parçalar kendi içinde belli bir görevi yerine getirirler ve bu ufak parçaların test edilmesi daha büyük modellere göre oldukça basittir.

Unit Test

JEST

Enzyme

React Component’larına Unit Test Yazmak

React bilindiği gibi farklı bir render mekanizmasına sahip. Component’ları test edebilmek için bir şekilde bu render mekanizmasını test sırasında çalıştırmak gerekiyor. Öncelikle test için kullanacağımız araçlardan bahsedelim, ardından örnek ile bir component test sürecini inceleyelim.

Örnek Senaryo:

Test etmek için bir menü yapısı düşünelim. Menüye ait elemanları bir rest servis ile veya farklı bir şekilde dışarıdan almayı planlayalım. Component’ımızı datanın kendisinden haberi olmayacak şekilde tasarlayacağız. Sadece kendisine pass edilecek field’ları ve data yapısını biliyor olacak(presentational component). Buna göre component geliştirelim.

Component Yapısı:

Tasarladığımız component basitçe kendisine pass edilen array tipindeki menü listesini bir ul içerisine li > link > {name} formatında map ederek render ediyor ve kendi stilini veriyor. State tutmadığı için Stateless Component yapısında yazmayı tercih ettim. Yazı daha çok react geliştiricilerine hitap ettiği için kod detayına girmeyeceğim.

Test:

Test kodumuz yukarıdaki yapıya sahip component’a istediği tipte prop’ları pass edecek ve ardından enzyme ile shallow rendering yaparak test case’lerimizi yazacağız. Syntax olarak hemen hemen tüm araçlar için aynı prensipler buradada geçerli.

Class isimleri ile Component içindeki Elemanlara Erişmek:

Yukarıdaki test örneğinde React Router’ın Link’ini find ile yakaladık. Ancak bu her zaman istediğiniz bir kullanım şekli olmayabilir. Bu nedenle style class isimlerinden elementleri yakalamak isteyebiliriz. Bunun için aşağıdaki gibi pratik bir çözüm uygulayabilirsiniz.

Integration Test

UI Test

UI testleri aslında en keyifli test türü diyebilirim. Bir uygulamayı tamamladıktan sonra bazen istemsiz hatalar yaparak değiştirmememiz gereken bir şeyi değiştirerek tasarım bütünlüğünü ve markup’ı bozabiliriz. İşte bu hataların önüne geçebilmek için UI testleri yazmamız gerekiyor. Başlık alanında h1 tag’i kullanılması uygulama süresince istediğim bir şey ise eğer bu değişirse testin fail olmasını beklerim. Bu doğrultuda yaptığımız şey component içerisinde başlık alanına ait node h1 mi? değil mi? kontrolü yapmak. Bir süre sonra bu çok sıkıcı bir hal almaya başlıyor ve sürekli aynı şeyleri tekrarladığınızı hissediyorsunuz.

SnapShot Test

SnapShot Test Örneği:

SnapShot Çıktısı:

Component’ı Update Edelim:

Test Çıktısı:

End to End

İşlevselliğin test edilmesi, herşeyin düzgün çalışıp çalışmadığının test edilmesi olarak özetlenebilir. Adındanda anlaşıldığı gibi uçtan uca test yapmayı gerektiriyor. Functional test olarakta isimlendirenler var. Aslında hepsi aynı şeyi ifade ediyor.

  • Sayfayı aç
  • Üye ol linkine tıkla
  • Üye ol formu açılıyor mu?
  • Üye ol formunu doldur
  • Üye ol butonuna tıkla
  • Kayıt başarılı mesajı alınıyor mu?
  • Form başarılı mesajı sonrası sayfa istediğim route’a redirect oluyor mu?
  • Formu eksik doldur
  • Kayıt başarısız mesajı alınıyor mu?

Selenium ile Automated Testler Yazmak

Selenium ile kullanıcı hareketlerine uygun otomatik çalışan testler yazabiliriz. Browser üzerinden önceden belirlenen kurallara uygun olarak çalışan test uygulamaları geliştirilebilir. Özellikle BrowserStack ile entegre olan otomasyonlar gerçekten büyük bir yükü omuzlarımızdan alıyor. Selenium bir çok programlama dili ile yazılabiliyor. Java, Ruby, Python, Node gibi. Hangi dile daha hakimseniz o dille testlerinizi yazabilirsiniz.

  • Ide: tarayıcı üzerinde çalışan bir plugin vasıtasıyla kolayca test case’lerin yazılması.
  • Webdriver: Biraz daha komplike işler yapmayı sağlayan ve tarayıcıya özel methodları kullanarak test yazmayı amaçlayan Ide’nin aksine geliştirme ortamına ihtiyaç duyan bir yenilik.
  • Grid: Dağıtık test otomasyonu geliştirmeyi amaçlar. İşletim sistemi ve donanım özelliklerine göre farklı browser’lar üzerinde testleri paralel olarak çalıştırmaya ve sonuçları pratik bir şekilde görmeyi sağlar.

Navigate:

Basitçe webdriver kullanarak firefox tarayıcısı üzerinde http://www.google.com domain’ini açtıralım.

Örnek Test Case:

Artık yapacağımız işlemlerin en önemli bölümünü elementlerin kontrolü kapsıyor. Webdriver’da tüm async işlemler promise döndürür.

Sonuç:

Manuel Test

--

--

engineer, previously @eBay, sci-fi addict. JavaScript, Frontend, Software Architecture

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
Oğuz Kılıç

Oğuz Kılıç

engineer, previously @eBay, sci-fi addict. JavaScript, Frontend, Software Architecture