Bölüm 3: Ekranlarımızı Test Edelim

Kurtuluş Ahmet TEMEL
4 min readMay 4, 2020

--

Selamlar Arkadaşlar,

Bu yazımızda Bölüm 2'de kodladığımız ekranlar için birim testi yazacağız. Daha öncede belirttiğim gibi bence bir mimarinin üstünlüğü ne kadar kolay birim testi yazılabildiği ile ölçeklenebilir. Ben de şimdi mümkün olduğu kadar basit ama işlevsel test örnekleri üzerinden yazımızı ilerleteceğim.

Ama hepsinden önce size bir başka kavramdan bahsetmek istiyorum. TDD yani Test Driven Development olarak ifade edeceğimiz bu kavramı dilimize Test Güdümlü Geliştirme olarak çevirebiliriz.

https://www.codecademy.com/articles/tdd-red-green-refactor

Ana felsefesi Red-Green-Refactor olan TDD bir kaç adımla test yazmamızı sağlıyor;

1. Adım: Test yazılır ve başarısız olur. (Red)
2. Adım: Testin başarılı olması için geliştirme yapılır (Green)
3. Adım: Kod refactor edilir. (Clean Code Refactoring + Tests)

Adımlardan da anlaşılacağı üzere önce test senaryoları çıkarılır. Ve işe önce test yazmaktan başlanır. Yukarıdaki adımlarla geliştirme devam ettirilir. Tabi bu kavrama uyulması burada yazdığım kadar kolay değil. 🤣 Nitekim biz bu seride buna uymadık.

Yine bu kavramda etkin şekilde kullanılan ve test fonksiyonlarının okunulabilirliğini artıran

  • Given (Subject)
  • When (Condition)
  • Then (Output)

kalıbını test fonksiyonlarımız içerisinde kullanacağız.

Given bölümünde test edeceğimiz özneyi(sut) işlem için hazırlıyoruz. When bölümünde ise gerçekleştireceğimiz test koşulunu çalıştırıyoruz. Then bölümünde ise testimizin geçerliliğini kontrol ediyoruz.

Şimdi gelelim testlerimizi yazmaya. Bu işlem için daha önce bahsettiğim Clean Swift şablonu ile New File..-> Clean Swift -> Unit Tests yolunu izleyerek test dosyalarımızı oluşturalım.

Tüm dosyalar bağlantıları sağlanmış ve Given-When-Then yorumları bırakılmış halde hazır. Şimdi testlerimizi yazacağız.

https://rubygarage.s3.amazonaws.com/uploads/article_image/file/1797/clean-swift-1x.png

Bu resimden tekrar hangi yapıların birbiri arasında bağlantılı olduğunu hatırlayalım. Test yazarken ihtiyacımız olacak 🙂

Interactor’ı Test Edin

Öncelikle her test etabında yapacağımız gibi bir sut (subject under test) oluşturarak başlayalım. Sut, sınıf içerisinde test edeceğimiz yapıyı temsil etmektedir. Bu kısımda Interactor içerisinde yer alan fetchRockets()fonksiyonu için test yazacağız. Şimdi Interactor’ın bağlı olduğu Presenter ve Worker için Spy sınıflar oluşturalım.

Bir test metodu işlevsel olabilmesi için öncelikle test ön eki ile başlamalıdır. Bu method bir şeyi test etmeli yani bir test çıktısı olmalı ve test metodunun ismi ne yapacağını tam olarak belirtmelidir. 🙂 Hikaye yazar gibi method ismi yazalım. 😜 Test metodumuz aşağıdaki gibi olacaktır.

Metod içerisindeki Given kısmında Presenter ve Worker için Spy bağlantıları kuruyoruz. Ardından When kısmında isteğimizi gerçekleştiriyoruz. Then kısmında ise gerçekleşen istek sonucunda Presenter ve Worker’ın ilgili metodlarını çağırılıp çağrılmadığı kontrol edilir.

Presenter’ı Test Edin

Yukarıdaki bağlantı resminden göreceğimiz üzere Presenter sadece View Controller ile bağlantılıdır. Bu sebeple bizim bir RocketsDisplayLogicSpy sınıfına ihtiyacımız olacak.

Şimdi Presenter içerisinde yer alan presentRockets()fonksiyonu için test yazalım.

Burada spy tanımı yaptıktan sonra bir rockets array’i oluşturuyoruz. Bu array’i Response modelimize verelim. Ardından ilgili fonksiyonu çağırarak Response model değerini display etmek üzere yazılan View Controller metodunun çağrılıp çağrılmadığını görelim.

View Controller’ı Test Edin

Bu kısımda yazılabilecek çok metod olduğundan size sadece temel iki metodu aktaracağım. Spy sınıflarımızı oluşturalım.

Görüldüğü üzere RocketsBusinessLogic ve ekranımızda kullandığımız UITableView için Spy sınıfı yazdık. “Her şeyi anladık da TableView için neden Spy yazıyoruz.” diyebilirsiniz. Hemen açıklıyorum.

Bu Spy sınıfını kullanarak View Controller’da yer alan displayFetchedRockets()fonksiyonu içerisinde reloadData çağrımının yapılıp yapılmadığını kontrol edeceğiz.

Bir diğer test fonksiyonumuzda ise yine displayFetchedRockets()fonksiyonu çağrımı sonrası tableView Cell içerisine doğru datanın basılıp basılmadığını kontrol edeceğiz.

Worker’ı Test Edin

Son olarak ağır abimiz Worker’ı da test ederek işimizi bitirelim.

Burada öncelikle şunu belirmeliyim. Bölüm 2 içerisinde oluşturduğumuz Worker yapımıza ben bir kaç eklemede bulundum. Bu eklemeyi daha net görebilmeniz adına yazının sonunda yer alan repomuza giderek kodumuzu inceleyebilirsiniz.

Şimdi Worker içerisinde kullanmak için RocketsAPI Spy sınıfı oluşturalım.

Spy sınıfımız hazır olduğuna göre artık Worker içerisinde yer alan fetchRockets()fonksiyonunu test edebiliriz.

Burada expectation oluşturduğumuz kısımları özellikle belirtmek istiyorum. RocketAPISpy içerisinde 1 saniye olarak belirlediğimiz işlem süresinden yola çıkarak timeout değeri olarak 1.1'i kullanıyoruz. Sonrasında ilgili isteği yaparak kontrollerimizi ilerletiyoruz.

Testlerimizi çalıştıyoruz ve sonuuuuç……

Yazdığımız kodun son halide buradan ulaşabilirsiniz. Umarım faydalı olmuştur. Başka bir yazıda görüşmek üzere.

--

--