FRONTEND TDD GEÇİŞ AŞAMALARI

Herkese merhaba, bu yazımda frontend tarafında Test Driven Development a geçiş aşamalarından, test çeşitlerinden ve Jest’den bahsedeceğim. Production ortamında olan ve gitgide büyüyen projeler için tüm projeyi tek tek manuel olarak test etmek zamanla yetersiz kalabilir. Bu sebepten projedeki bugları minimuma indirmek ve kodun daha kaliteli olmasını sağlamak amacıyla Test Driven Development yöntemine geçmek ve unit testler yazmaya başlamak yerinde bir karar olacaktır. Şimdi dilerseniz test yöntemlerinden başlayalım.

1: UNIT TEST

Unit testlerde tek bir function, method, procedure ve module testleri yapılır. Unit testler kodun doğruluğunu ve kodda beklenen doğru sonucun verilip verilmediğini test eder. Birim testlerde tüm bileşenler ayrı ayrı test edilir. Örneğin bir fonksiyonun test edilmesi veya bir döngünün düzgün çalışıp çalışmadığı birim testin kapsamına girer.

2: COMPONENT TEST

Component testleri her bir component’in birbirinden bağımsızlığını test etmek için kullanılır. React uygulamaları component bazlı olduğu için bu componentlerin testi de oldukça önemlidir. Örneğin bir çok componente sahip bir web uygulaması düşünelim ve her componentin bir de alt bileşeni olduğunu varsayalım. Diğer componentler ile entegrasyon dikkate alınmadan her modülün ayrı ayrı test edilmesi ise component testleri olarak adlandırılır.

3: SNAPSHOT TEST

Snapshot testleri web uygulamalarında UI üzerinde gerçekleşen beklenmedik değişimlerin önüne geçmeyi garanti eder. Snapshot test ui ‘in bir ekran görüntüsünü alır ve bunu her state değişikliğinde UI’ın önceki durumu ile karşılaştırır.

Tdd konusu oldukça geniş bir konu olduğundan ve bunu önceki yazımda anlattığımdan dolayı bu yazımda unit testlerden bahsedeceğim. Öncelikle unit test için kullanılan test frameworklerine ve projemizde neden bu frameworkleri tercih ettiğimize bir bakalım:

Neyi Test Edeceğimi Nerden Bileceğim?

Test classları yazmaya nerden başlayacağınızı bilmiyorsanız lütfen okumaya devam edin.

• Koda yeni bir method veya fonksiyonellik ekleyeceğimiz zaman bu eklenen yeni kodun nereleri etkileyeceğini ve nerede bir bug a sebep olabileceğini önceden kestirmek oldukça zordur.
• Önceden yazılmış ve test classlarının olmadığı bir projeye dahil olduğunuzda neyin neden yazıldığını anlamayabilirsiniz ve yeni yazacağınız kod daha fazla bug lara sebep olabilir
• Test Kodları projenin bir nevi dökümanı gibidir. Sadece test kodlarına bakarak bir componentin, metodun veya classın ne işe yaradığını net bir şekilde anlayabilirsiniz.
• Test kodları bug ları minimum düzeye indirmemizi sağlar ve kod kalitesini arttırır.

Bu senaryolardan yola çıkacak olursak elimizde bir method ve methodun bir return değeri olduğunu varsayalım. Test akış şeması aşağıdaki şekilde olacaktır.

1:Test etmek istenilen fonksiyon test classına import edilir.

2: Test fonksiyonuna bir input değeri verilir.

3: Beklenen sonucun ne olacağı tanımlanır.

4: Beklenen sonucun method çıktısına eşit olup olmadığı kontrol edilir.

5: Eşit ise test başarılı olur.

6: Eşit değilse kod refactor edilir.

Şimdi kullanılan frameworklere geçelim:

KULLANILAN TEST FRAMEWORKLERİ

JEST

• Facebook tarafından geliştirilmiş olan bir Javascript test Framework’tür.
• Komut satırından aşağıdaki şekilde install edilebilir.

npm install --save-dev jest

• Jest çok hızlı bir frameworktür:

Test hızlarında ciddi zaman kazandırır. Örneğin AirBnb Mocha’dan Jest e geçti ve testlerin toplam çalışma süresi 32 çekirdekli ağır tipte bir makinede 12 dakikadan 4.5 dakikaya kadar düştü. Peki Jest nasıl bu kadar hızlı?

• Paralelleştirme:

Jest kullanımın yanısıra jest ile birlikte başka frameworklerin kullanımına da izin verir.

• Jest önce en yavaş testleri çalıştırır.

Böylelikle, tüm çekirdeklerin maksimum düzeyde kullanılmasını sağlar

• Jest içersinde matcher, spies ve bunun gibi bir çok extension barındırır.

Jest Jasmine tabanlıdır. Jasmine’in tüm özelliklerini miras almış üzerine yeni özellikler ekleyerek büyümeye devam etmiştir.

• Jest kullanımı diğer test frameworklerine göre oldukça basit ve anlaşılırdır.
• Jest snapshot testleri de yapar.
• Jest testleri watch komutu ile koşmamızı da sağlar.

Bu komutu aşağıdaki şekilde komut satırında çalıştırdığımızda,

$ npm run test -- --watch
Watch Usage
 › Press a to run all tests.
 › Press f to quit "only failed tests" mode.
 › Press p to filter by a filename regex pattern.
 › Press t to filter by a test name regex pattern.
 › Press q to quit watch mode.
 › Press Enter to trigger a test run.

Görüldüğü gibi bize Watch usage dönmektedir. İstediğiniz seçeneklerden birini seçerek istediğinizi testi koşabilirsiniz.

Neden Jest kullanıyoruz ve Jest’in avantajları ile ilgili olarak anlatacaklarım bu kadar. Şimdi projedeki örneklerine geçelim:

Yukarıdaki metodu incelediğimizde networkten frontend e gelen service types’lara göre renk değişikliğini sağlayan bir metod olduğunu görüyoruz. Ayrıca içerisinde birden fazla if koşulu da bulunmakta. Bize bir değer return etmektedir.

Bu method uniqe bir metoddur. Tek bir amaca hizmet eder. Bu metodun testini yazmak bu sebepten ötürü çok zor olmayacaktır. Test koduna geçelim:

Yukarıdaki test metodunda önce methodu test classına import ettik. Ardından beklenen result ve gerçek result karşılaştırması yapacak olan kodumuzu yazdık.

describe(name,fn) => Birden fazla birbiri ile alakalı test satırını içerisinde bulundurur.

it or test => İkisi de aynı işlevi sağlar. it veya test içerisinde test etmek istediğiniz metodu anlaşılır ve kısa şekilde anlatmanız beklenir. Bir describe içersinde birden fazla satırda it veya test yazabilirsiniz.

expect => Adından da anlaşılacağı gibi beklenen değerin ne olduğunu gösteren bir test methodudur.

Yukarıdaki örnekte Service typeslar array olduğu için bir map ile dönmektedir. Bu arraylardan herbirinin color props özelliği ayrı ayrı karşılaştırılmaktadır. Karşılaştırma işlevi toEqual() metodu ile yapılmaktadır. Metodda dönen değerin yani gerçek sonucun beklenen sonuca eşit olup olmadığı verilen input a göre kontrol edilir.

Test çıktısı ise aşağıdaki gibi olacaktır:

Görüldüğü üzere yazdığımız contractedCompanies.test.js sınıfı testten geçmiştir.

Şimdi bir de bu metodun testten fail olduğu yani testi geçemediği bir test class yazalım:

Kod çıktısı aşağıdaki gibi olacaktır:

Gördüğünüz üzere ilk satırdan kaynaklanan bir hatadan dolayı test fail etti. Beklenen sonuç “red” iken test classı bize “yellow” döndü. Yani expected result gerçek result’a eşit olmadığı için testimiz başarıya ulaşamadı.

İşte bu kadar. Jestin çok fazla syntax ı bulunmaktadır. Bunların hepsini tek bir dökümanda yazmam mümkün olmadığı için test classlarını yazarken aşağıdaki linkte bulunan Jest’in kendi dökümanından faydalanmanızı şiddetle tavsiye ederim.

Getting Started · Jest

Jest ile alakalı ilk örneğimizi bu yazımda birlikte yapmış olduk. Sonraki yazılarımda yine Jest örnekleri ile devam edeceğim. Herhangi bir soru ve önerilerinizi lütfen yazın. Herkese iyi çalışmalar…