Junit ile Controller Testi

0 728

Unit test konusu kendi gözlediğim kadarıyla çoğu zaman yapılmak istenen fakat hiç yapılmayan bir pratik. Bunun nedeni çoğunlukla zaman! Yani en azından bahane zaman!

Test yüzü görmeyen projeler inanıyorum ki bir yerlerde hayatlarına devam ediyor.

 

Yazmak istiyoruz, inanıyoruz ama vaktimiz yok!

Unit Test

Bir test methodu en temel anlamda üç adımdan oluşur. Farklı kaynaklarda farklı isimlendirmeler görülebilir fakat temel anlamda;

Given: testin ihtiyaç duyduğu  ile ilgili

When: test edeceğimiz methodun çağrılması

Then: methoddan beklediğimiz işleri yapıp yapmadığını doğruladığımız bölüm.

Doğrulama, doğru değerlerin cevap olarak dönmesi, beklediğimiz hatanız fırlatılması ya da başka methodları çağırıp çağırmaması olabilir.

 

  • Tek bir test methodu bir test senaryosunu gerçekleştirmelidir.
  • Bir method için birden fazla test senaryosunu yazılabilir/ yazılmalıdır.
  • Methodun bağımlılıkları sahte(mock) veriler ile sağlanır. Çünkü amaç methodun kendi görevini doğru yaptığını kontrol etmek.

 

Test Methodu İsimlendirme

İsimlendirme tabii ki burada da çok önemli. Kendi standardınızı oluşturabileceğiniz gibi, bir çok yerde görebileceğiniz standart isimlendirmeleri kullanabilirsiniz.

Kaldı ki böyle bir ihtiyacı testleriniz arttıkça kendiniz de gözlemleyeceksiniz.

Projelerde kullandığım standart aşağıdaki gibidir.

MethodName_StateUnderTest_ExpectedBehavior

dezavantaj: method ismi değişirse burası da değilmeli.

örnek: isAdult_AgeLessThan18_False

 

Bir çok projede gördüğüm isimlendirme ise aşağıdaki gibidir.

Should_ExpectedBehavior_When_StateUnderTest

dezavantaj: uzun ve should ve when kelimelerinin tekrarı

örnek: Should_ThrowException_When_AgeLessThan18

Diğer örnekler için aşağıdaki linklerden faydalanabilirsiniz.

https://medium.com/@stefanovskyi/unit-test-naming-conventions-dd9208eadbea

https://dzone.com/articles/7-popular-unit-test-naming

 

Controller Testi

Aşağıdaki Controller class’ı için test yazmayı deneyelim.

 

  • JUnit 5
  • Spring Boot 2.7.0
  • Mockito

 

Method

 

Methodu incelediğimizde sadece başka bir methodu çağırdığını görüyoruz yani sadece başka bir methoda bağımlılığı var. Dolayısıyla buradan gelecek veri methodumuzun kendi işine odaklanmasını sağlacak. Bunun gibi bağımlılıklarımızın olduğu yerleri sahte(mock) veriler ile sağlıyor olacağız. Çünkü amacımız method kendi üstüne düşen görevi doğru yapıp yapmadığı.

 

Unit Test

 

Method

Yine aynı şekilde çok benzer bir methodu inceleyelim ve testini yazmaya çalışalım.

UserService’in createUser methoduna bağımlı bir method görüyoruz ve aldığımız cevabı ResponseEntity objesine koyup dönüyoruz. Methodun görevi bu herhangi bir iş kuralı işletmiyor ve ya dallanma gerçekleşmeden görevini gerçekleştirmiyor.

 

 

Unit Test

Burada beklentimiz, bağımlı olduğu başka bir class’tan verinin gelmesi durumda kendi görevini doğru şekilde gerçekleştirebilmesi.

Peki bağımlı olduğu class’tan veri nasıl gelecek? Bu sorumuzun cevabı da mock! Test methodunda gördüğümüz gibi bağımlı olduğumuz method bizim istediğimiz değerler ile çağrıldığında bizim hazırladığımız bir obje cevap olarak dönüyor. Sonuç olarak artık beklentimiz methodun kendi görevini gerçekleştirebilmesi yani bu cevabı bize dönebilmesi gerek. Eğer biz de bu verilerin doğru geldiğini ispatlayabilirsek doğru bir test senaryosunu gerçekleştirmiş oluruz.

 

Bir sonraki yazıda servis katmanına testler yazacağız, görüşmek üzere.

 

Faydalı olması dileğiyle.

Email adresiniz yayınlanmayacaktır.