Birim Testi Nedir?

Mar 04 2023

Herkese merhaba, takım arkadaşım Fatmagül Polat ile Unit Testing tecrübemizi anlatan küçük bir yazı yazdık. İyi okumalar :) Birim testi, bir yazılımı en küçük biriminin tüm bağımlılıklarından yalıtılmış olarak çalıştırarak davranışını doğrulayan bir yöntemdir.

Herkese merhaba, ekip arkadaşım Fatmagül Polat ile Unit Testing tecrübemizi anlatan küçük bir yazı yazdık . İyi okumalar :)

Birim testi, bir yazılımı en küçük biriminin tüm bağımlılıklarından ayrı olarak çalıştırarak davranışını doğrulayan bir yöntemdir. Birim testleri, kod yazarak yazdığımız kodun davranışını doğrulamamızı sağlar ve yazılımın test edilebilir en küçük parçası olduğu için geliştiriciler tarafından birim testleri geliştirilir.

TDD nedir?

Test Odaklı Geliştirme, son yıllarda sıkça duyduğumuz ve yaygınlaşmaya başlayan bir uygulamadır. Temel olarak söylediği, uygulama kodunu yazmadan önce testinin yazılması gerektiğidir.

Neden birim testi ve faydaları geliştiriyoruz?

Birim testleri yazabilmenin birçok faydası var, bunlardan bahsetmeye çalışacağız.

TDD yaklaşımıyla geliştirme, herhangi bir işlevsel kod yazılmadan önce gereksinimlerin veya tasarımın kapsamlı bir şekilde gözden geçirilmesini gerektirir. Geliştirme için birim testleri yazarak başlıyoruz. Bu süreç, geliştireceğimiz özellikler üzerinde daha yoğun düşünmemizi sağlayacak ve sadece gereksinimlere odaklanmamızı sağlayacaktır. Doğrudan kodlamaya başlamak, geliştirme yaparken kodun tasarımına ve akışına odaklanmamızı biraz daha zorlaştırabilir. . Bu süreç, yalnızca gereksinimlere odaklanarak daha az hata yapmamıza ve daha basit ve temiz kod yazmamıza yardımcı olacaktır.

Unit test yazmanın bir faydası da geliştirme aşamasında oluşabilecek hataları fark edip düzeltme imkanına sahip olmanızdır. Bir hatanın ortaya çıkması ile saptanması arasında ne kadar çok zaman geçerse, hatayı çözmenin maliyeti de o kadar artar. Birim Testi, bu maliyet artışını önlememize yardımcı olacaktır.

Yazılımımız sürekli gelişiyor ve değişiyor, bu nedenle yazdığımız yöntemlerde değişiklik yapmamız gerekecek. İyileştirmeler veya değişiklikler beklenmeyen bir hataya neden oluyorsa, bu hata daha önce bu kod için yazdığımız testlerle yakalanır ve geliştirme aşamasında bunu fark edip önlem alabiliriz. Testleri yazılan bir sınıfa yeni bir özellik eklediğimizde genellikle eklenen özelliği test etmeye odaklanırız. Bu yeni özellik düzgün çalışıyor olsa bile, bu sınıfın şu anda gerçekleştirebildiği bir özelliği gerçekleştirememesine neden olabilir. Önceden belirlenmiş kajuları her zaman test edemeyiz. Bu gibi durumlarda, mevcut özelliklerin önceden yazılmış testlerine sahip olmak, istenmeyen veya gözden kaçan hatalara karşı koruma sağlar.

Eklenen her özellik mevcut birim testlerimizin başarısız olmasına neden oluyor ve bu birim testlerini yeniden düzenlememiz gerekirse aslında SOLID ilkelerinin "O" harfine aykırı oluyor, yani yöntemimiz değişime açık değil.

Bir birim testi yazmak, sizi kodun karmaşıklığını azaltmaya ve daha kaliteli kod yazmaya teşvik eder. Karmaşık ve çok fazla mantık içeren yöntemlerin testini yazmak oldukça zor olacaktır.

Her yöntemde yalnızca bir görev olacak şekilde, test edilebilir kod yazmak için kodumuzu daha küçük yöntemlere yazmamıza izin verecektir. Zamanla bu yaklaşımlar bizim için bir yazılım geliştirme kültürü oluşturacaktır.

Kodlarımızı test ederken tamamen dış bağımlılıklardan izole olmamız gerekiyor çünkü ilgilendiğimiz şey test etmek istediğimiz birimdeki kod. Dış bağımlılıkların davranışıyla ilgilenmiyoruz. Yazdığımız birimlerin bağımlı olduğu kod parçalarından bağımsız ve izole test etme ihtiyacı, bu birimleri soyutlamamıza ve kodu yeniden kullanılabilir küçük parçalara ayırmamıza olanak tanır. Dış bağımlılık örnekleri, işlemlerin veritabanına çağrıldığı yöntemler, dış kaynak kullanımı vb.

Test edilebilir kod yazarak, aslında SOLID ilkelerinden daha fazlasını uygulamaya başlıyoruz.

İyi yazılmış birim testleri, incelediğimiz işlev veya bileşene hangi girdiler verildiğinde hangi çıktıların alınacağına dair iyi örnekler içerir. Test edilen kodun mutlu bir yol olarak nasıl çalıştığını, son senaryoların ne olduğuna dair örneklerle görmemizi sağlar. Metotlarımızın nasıl tepki vereceğini birim testleri inceleyerek kolayca anlayabiliriz. Bu testler proje için belgeye özel olabilir. Testleri inceleyerek, yöntemlerin nasıl çalıştığını anlamada önemli ölçüde yardımcı olabilir.

Birim Testi nasıl geliştirilir?

TDD yaklaşımındaki adımlar şu şekildedir;

1. Geliştirme birimi testi.

2. Test başarısız olur.

3. Test başarılı olacak şekilde kodlanır.

4. Test başarılı olacaktır.

5. Kod yeniden düzenlenir.

Bu adımlara başlamadan önce testini yazacağımız sınıfların ve metotların deklarasyonunu yapmak gerekiyor. Öncelikle yöntemlerin testini yazıp ardından bu testin başarısız olduğunu görmeli, ilgili yöntemi kodlamalı ve test başarılı olduktan sonra işleme devam etmeliyiz.

Mevcut yöntemlerimiz için bu süreçleri tamamladıktan sonra tüm testlerimizi çalıştırır ve test yöntemlerimizin başarılı bir şekilde çalışmasını bekleriz. Bir test yönteminin başarılı olması için yaptığımız iyileştirme, diğer testlerin başarısız olmasına neden olabilir. Bu durumda kodu refactor edip testler tekrar başarılı olduktan sonra işlemi tamamlayacağız.

TDD yaklaşımının dışında, geleneksel yazılım geliştirme sürecinde birim test yöntemleri yazmaya başlıyoruz.

Özetle;

Günün sonunda, birim testinin amacı sadece projemizde birim testleri olduğunu söylemek olmamalıdır. Gerçekten amacımıza hizmet eden birim test yöntemleri yazmak bize çok şey katacaktır. Bu sayede test edilebilir kod yazmaya çalışarak daha kaliteli bir kod geliştirme kültürüne sahip olacağız. Kodumuzdaki bir iyileştirmenin diğer davranışları nasıl etkileyeceğini ve nerede hata yapabileceğimizi tahmin ederek hataları en erken aşamada fark etmemize yardımcı olacaktır.

Bir sonraki yazımızda birim test metotlarını nasıl geliştirdiğimizi ve ilgili süreçleri örnekleyerek açıklamaya çalışacağız. Yakında görüşürüz