Unit Test Nedir ?
Merhabalar herkese, ekip arkadaşım Berkin Ergürbüz ile Unit Test konusunda edindiğimiz tecrübeler hakkında küçük bir yazı yazdık.
Herkese Keyifli Okumalar 🙂
Unit test bir yazılımın test edilebilir, en küçük biriminin tüm bağımlılıklarından izole bir şekilde çalıştırılarak davranışını doğrulayan bir metoddur. Unit testler yazdığımız kodun davranışını yine kod yazarak doğrulamamızı sağlar.Yazılımın en küçük test edilebilir parçası olduğu için unit testler yazılım geliştiriciler tarafından geliştirilir.
TDD NEDİR?
Test Driven Development son yıllarda sıkça duyduğumuz ve yaygınlaşmaya başlayan bir pratik. Temelde söylediği şey uygulama kodunu yazmadan önce testinin yazılması gerektiğidir.
Unit Testi Neden Yazarız ve Bize Kazandırdıkları Nelerdir ?
Unit test yazabiliyor olmanın birçok getirisi vardır, bunlardan bahsetmeye çalışacağız.
TDD yaklaşımı ile geliştirme yapmak, herhangi bir işlevsel kod yazılmadan önce gereksinimlerin veya tasarımın kapsamlı bir şekilde gözden geçirilmesini gerektirir. Geliştirmelere unit testleri yazarak başlarız. Bu süreç bizlere geliştirecek olduğumuz feature üzerinde daha yoğun düşünmeye yönlendirecek ve yalnızca gerekliliklere odaklanmamızı sağlayacaktır. Direkt olarak kodlamaya başlıyor olmak geliştirme yaparken kodun tasarımına ve akış düzenine odaklanmamızı biraz daha zorlaştırabilir. Bu süreç bizim daha az hata yapmamıza ve yalnızca gerekliliklere odaklanarak daha sade ve temiz kod yazmamıza yardımcı olacaktır.
Unit test yazıyor olmanın bir faydası da oluşabilecek hataları henüz geliştirme aşamasında fark edip, bu hataları düzeltebilme fırsatını yakalıyor olabilmektir. Bir hatanın oluşması ile fark edilmesi arasında ne kadar zaman geçerse, hatanın çözülme maliyeti de o kadar artacaktır.Unit Test bize bu maliyetin artışını engellemek için yardım edecektir.
Yazılımlarımız sürekli gelişen ve değişen yapıdadırlar.Bu sebepten yazmış olduğumuz metodlarımızda değişiklikler yapmamız gerekecektir. Yapılan geliştirmeler veya değişiklikler beklenmedik bir hataya sebep oluyorsa bu hata daha önce bu kod için yazmış olduğumuz testler tarafından yakalanacaktır ve henüz geliştirme aşamasında bu durumu fark edip gerekli aksiyonu alabiliriz. Testleri yazılmış bir sınıfa yeni bir özellik eklediğimizde genellikle eklenen özelliğin testlerine odaklanırız. Bu yeni özellik düzgün çalışıyor olsa bile bu sınıfın mevcut durumda yerine getirebildiği bir özelliği yerine getirememesine sebep olabilir. Daha önceden belirlenmiş olan caseleri her zaman test etmemiz mümkün olmayacaktır. Böyle durumlarda var olan özelliklerin önceden yazılmış testlerinin olması istenmeyen veya gözden kaçan hatalardan korur.
Eklenen her özellik var olan unit testlerimizin fail olmasına sebep oluyor ve bu unit testleri tekrardan düzenlememiz gerekiyor ise aslında SOLID prensiplerinin “O” harfine yani metodumuz gelişime açık değişime kapalı olma ilkesine ters düşmektedir.
Unit test yazıyor olmak koddaki karmaşıklığı azaltmaya ve daha kaliteli kod yazmaya teşvik eder. Karmaşık ve birçok logic’i içinde barındıran metotların testini yazıyor olmak epey zorlayacaktır.
Test edilebilir kod yazmak için kodlarımızı daha ufak metotlara ve her metodunda yalnızca tek bir görevi olacak şekilde yazmamıza vesile olacaktır. Zamanla bu yaklaşımlar bizler için yazılım geliştirme kültürü oluşturmasını sağlayacaktır.
Kodlarımızın testini yazarken dış bağımlılıklardan tamamen izole olmamız gerekir çünkü bizim ilgilendiğimiz konu test etmek istediğimiz birimde yer alan kodlardır. Dış bağımlılıkların davranışları ile ilgilenmeyiz. Testini yazdığımız birimlerin bağımlı olduğu kod parçalarından bağımsız ve izole bir şekilde test etme gereksinimi bu birimleri soyutlayabilmemizi ve tekrar kullanılabilir (reusable) küçük parçalar halinde kodu tasarlayabilmemizi sağlar. Dış bağımlılıklara örnek olarak; veritabanına işlemlerinin çağırıldığı metotlar, dış kaynak endpoint ler vb.
Test edilebilir kod yazarak aslında SOLID prensiplerini daha fazla uygulamaya başlarız.
Unit Testi Nasıl Yazarız?
TDD yaklaşımında aşamalar şu şekildedir;
1. Test geliştirilir.
2. Test başarısız olur.
3. Test başarılı olacak şekilde kodlama yapılır.
4. Test başarılı olur.
5. Kod refactor edilir.
Bu adımlara başlamadan önce testini yazacağımız sınıf ve metotların bildirimini yapmak gereklidir. Önce metotların testini yazıp ardından bu testin başarısız olduğunu görüp, ilgili metodu kodlayıp testin başarılı olmasından sonra ki süreci devam ettirmeliyiz.
Var olan metotlarımız için bu süreçleri tamamladıktan sonra tüm testlerimizi çalıştırarak test metotlarımızın başarıyla çalışmasını bekleriz. Bir test metodunun başarılı olması için yaptığımız geliştirme diğer testlerin hata almasına sebep olabilir. Bu durumda kodu refactor ederek tekrar testlerin başarılı olmasının ardından süreci tamamlamış oluruz.
TDD yaklaşımının haricinde geleneksel yazılım geliştirme sürecinde unit testleri metodu yazdıktan sonra yazmaya başlarız.
Özetle;
Günün sonunda unit testin amacı sadece projemizde unit testlerimizin olduğunu söylemek olmamalıdır. Gerçekten amacına hizmet eden unit test metotları yazıyor olmak bizlere birçok şey kazandıracaktır. Böylelikle test edilebilir kod yazmaya çalışarak daha kaliteli kod geliştirme kültürü edinmiş olacağız. Kodumuzdaki bir geliştirmenin diğer davranışları nasıl etkilediğini ve nerelerden hata alabileceğimizi ön görerek hataları en erken safhada fark etmemize hizmet etmelidir.
Bir sonraki yazımızda unit test metotlarını nasıl geliştiririz ve ilgili süreçleri örnekleyerek anlatmaya çalışacağız. Görüşmek üzere 👋🏼
Tüm önerileriniz ve feedbackleriniz için mail adreslerimiz;
Berkin — berkinergurbuz@gmail.com
Fatmagül — polat.ftmgl@gmail.com
Yazının İngilizce versiyonu :
https://medium.com/@berkinergurbz/what-is-the-unit-test-4bc4178cdd30
