Test Driven Development (TDD) nedir?

//Test Driven Development (TDD) nedir?

Konuya ülkemizden gireceğim; bir yazılım geliştirilirken çoğunlukla önce uygulama yazılır, yazılımcının öngörüsüyle olabildiğince hatalar engellenmeye çalışılır if else, switch case,  throw catch derken hata engellenmeye çalışılır. Hata alan kullanıcı istediğim sonuç dönmüyor, sayfa patladı, böyle bir hata var vs, geri dönüş yapar ve yazılımcı onu çözer. Acı ama gerçek, döngü böyle dönüyor.

CRM, ERP gibi büyük projeler bile böyle yapılabiliyor, hepsi mi böyle? tabi ki hayır. ama bu şekilde çalışan büyük şirketler gördükten sonra, bir SQL tablosunda 192 kolon (evet yanlış değil bir tablo 192 kolon) olan ERP projesi gördükten sonra konuya dikkat çekmek istedim. Tamam belki Test, TDD kullanılmadan yorucu ve maliyeti fazla da olsa proje geliştirilebilir ama normalizasyon ve ilişkisel veri tabanı mantığı nedir bilmeden nasıl böyle büyük projeler yapılıyor yüzbinlerce, milyonlarca liraya satılıyorlar anlamış değilim 🙂 Sözde kurumsal firmalar havalarından da geçilmezler 🙂

Neyse kaldığımız yerden devam. İkinci durum ise  uygulama yazılır, sonrasın da eğer vakit var ise ve yönetim de izin verirse 🙂 uygulamanın testleri yazılır. Testler çalıştırılarak yazılan kodun doğru olup olmadığı kontrol edilir. Doğru değilse düzeltilerek testler tekrar çalıştırılır. Bu döngü test durumlarının tamamı doğru çalışana kadar devam eder. Biraz daha kurumsal firmalar zaman ve maliyet gibi durumlardan dolayı böyle bir süreç gerçekleşebiliyor. Bir şey demeyin hiç yoktan iyidir. Hiç test yazmamaktansa kötü de olsa test yazmak daha iyidir.(Murat ÖDÜNÇ) Ben nasıl iyi test yazarım iyimi yazarım kötü mü yazarım derdindeyken Laravel’ci arkadaş böyle bir cümle kurdu çok hoşuma gitti, hak vermemek elde değil.

Test Driven Development‘ta  ise uygulama geliştirilmeden yani kod yazılmadan önce test yazılır. Daha sonra, yazılan testlere uygun, yani testleri geçecek kod yazılır. Bu yöntemle projeye başlamadan önce projeyle ilgili tüm senaryolar ortaya çıkartılır işin özü de budur. Olabilecek tüm senaryolara göre test durumları hazırlanır.  Yazılan kod tüm testleri geçene kadar kodlar basite indirgenerek düzeltilir yani refactor edilir. Bu yaşam döngüsüne Test-Driven Development (TDD) yani Test Güdümlü Geliştirme denilmektedir. Ayrıca Test Driven Development diğer adlarıyla Test First Development ve Test Driven Design olarak da bulabilirsiniz.

Test-Driven Development yaşam döngüsü aşağıdaki şekildeki gibidir,

Test-driven_development

Yazıyla kısaca anlatmak biraz zor yalnız diyagramı özetle anlatmak gerekirse.

Senaryoları belirle – Testleri yaz  – Testleri çalıştır (Hata varsa) – Kodları yaz (düzenle) – … – Testleri çalıştır (Bütün testler başarılı ise) – (Hata yoksa) Kodlamayı tamamla.

TDD süreci basit gibi görünse de bir çok yazılım firmasının (para, para, para) uygulamaya sıcak bakmadığı bir yöntemdir. Fakat bu yöntemin kullanıldığı projelerde ortaya çıkan yazılım, hem kalitesi artmakta hem de uzun vadede yazılım geliştirme sürecini kısaltmaktadır. Örnek vermek gerekirse;

Bir çalışanın maaşını hesapladığınızı düşünün bunu etkileyen onlarca durum söz konusudur. Evli/Bekar, sakatlık, emeklilik, primler, Teknokent vb bir yerde bulunmasından kaynaklı vergi indirimi, net veya brüt olması çalışanın eline geçecek ücret miktarını değiştirmektedir. Kanunda yapılan bir değişiklik olduğunu ve bir kaç tane maddenin değiştiğini toplamda 30 tane madde olduğunu varsayalım.

TDD kullanılmayan bir yazılım geliştirme sürecinde kodlar düzenlendikten sonra tüm senaryoları test uzmanı tek tek kontrol etmek zorunda kalacaktır. Bunun maliyeti saatler bazen günler alabilecektir. Hata fark edildiğinde süreç başa dönecek ve kodlar düzenlenecek tekrar bir kişi tarafından test edilmek zorunda kalacak ve bu süreç böyle devam edecektir.

TDD kullanıldığın da testleri ve kodları düzenledikten sonra testleri çalıştırdığınızda saniyeler içinde test edilecektir. hata var ise düzeltilip tekrar saniyeler içinde test edebileceksiniz.

Test yazmak belki vakit kaybı gibi gelebilir ama uzun vadede daha hızlı yazılım geliştirmeye yardımcı olmaktadır.

Test Güdümlü Geliştirme metadolojisi sürecinin yazılım geliştirme ve test aşamaları 3 adımdan oluşmaktadır.

tdd-red-green-refactor

 

Red Cycle Nedir? (Hatalı Sonuç Döndüren Test)

Bu durum, geliştireceğiniz uygulamaların hangi durumlarda hata vereceğini kestirip bu durumlarda nasıl sonuçlarla karşılaşacağınızı öğrenmenizi sağlayacaktır. Örnek uygulamamız da hesaplama işlemleri var ise ve bu hesaplama işlemlerinin birindeki bölme işleminde bölenin 0 olma durumu söz konusu ise bu durumu ortaya çıkartan bir senaryoya uygun test metodu hazırlayacaksınız. Hazırladığınız testi çalıştırdığınızda olmasını beklediğiniz durumla, yani hatayla karşılaşmanız gerekmektedir. Hata oluşmadığı durumda kodda bir yanlışlık var demektir. Test yazarken önce kırmızıyı görün, hatayı görün sonra düzeltip yeşile çevirin prensibi önemlidir 🙂

Green Cycle Nedir? (Başarılı Sonuç Döndüren Test)

Green Cycle, başarılı sonuçlar ortaya çıkartan test durumları yazma işlemidir. Bu test sonucunda ortaya çıkan değer ile çıkmasını düşündüğünüz (olması gereken) değerin aynı olması (ya da ilgili koşula uygun olması) beklenmektedir. Örneğin, maaş hesaplama algoritmanızın testlerinde gönderdiğiniz parametrelere göre olması gereken sonucu tanımlıyorsunuz (parametrede x y z değerlerini atıyorsunuz, hesap sonucunu t değerinin olması gerekiyor). Testi çalıştırdığınızda gönderdiğiniz değerlerin karşılığında aynı sonuç (t sonucu) oluşuyorsa kodunuz doğru, farklı sonuç oluşuyorsa (t dışında bir değer oluşuyorsa) kodunuz yanlış anlamına gelir.

Refactor Nedir? (Kod Temizleme)

Refactoring, testlerden olması gereken sonuçları elde ettikten sonra yazdığınız dokları daha basit, anlaşılır ve geliştirmeye açık (daha kolay düzenlenebilir) bir hale getirme işlemidir. Refactoring uygulanmış bir kod daha temiz olduğu için okuması daha kolaydır. Örneğin, projede aynı kodların tekrarlandığı durumlarda tekrarlanan kodları tek bir metoda çevirerek metodu çağırmak daha iyi olacaktır. Çünkü kod 3-5 farklı yerde olduğunda kodda değişiklik yapılması gerektiğinde hepsini ayrı ayrı değiştirmek zorunda kalacaksınız ama tek bir metoda düşürdüğünüzde metot da değişiklik yapmanız çağrılan bütün yerler için geçerli olacaktır. Kodunuzu daha hızlı  geliştirmenizi sağlayacaktır.  OOP’u (nesneye dayağı programlama) iyi öğrenmeniz refactor için kolaylıkta sağlayacaktır.

Biraz uzun oldu ama konu önemli olduğu için yapacak bir şey yok 🙂

Sağlıcakla kalın…

 

By |2017-09-27T12:22:52+00:00Ağustos 10th, 2015|TDD & Test|3 Comments

3 Comments

  1. zafer 03/03/2016 at 09:59 - Reply

    “Test Driven Development‘ta ise uygulama geliştirilmeden yani kod yazılmadan önce test yazılır.” bu tanımlama Test First Development’a (TFD) daha uygun. 🙂 emeğinize sağlık

    • alikoprulu 06/05/2016 at 16:31 - Reply

      Bu konuda haklısınız “Test Driven Development” diğer adlarıyla “Test First Development”, “Test Driven Design” olarak anılmaktadır yani bahsettiğimiz şey aynı 🙂 Yalnız yazıda eklememişim yanlış anlama olmaması için düzenleme yaparım.

  2. Cemal 08/09/2017 at 19:14 - Reply

    Çok güzel bir açıklama olmuş. Teşekkürler

Leave A Comment