Giray Kurekci

1. Test Driven Development
Test Driven Development Nedir ?
TDD'nin Tercih Edilmeme Nedenleri ?
TDD Zaman Kullanımı
TDD'nin Maddi Acidan Tercih Edilmeme Nedeni ?
TDD'nin Bize Getirileri
TDD'nin Cesitleri

2. Test Driven Development
Nedir ?
Test Driven Development diğer adlarıyla Test First Development, Test Driven Design olarak
anılmaktadır. İlk olarak Extreme Programming (XP) yazılım sürecinin oluşturucusu üstad Kent
Beck tarafından ortaya atılmıştır.Extreme programming(XP) ve günümüzdeki birçok Agile(çevik)
modern yazılım geliştirme süreçlerinin kodlama bakımından bel kemiğini oluşturmaktadır.
Test Driven Development’ın dışarıdan adını ilk duyduğunuzda geliştirdiğiniz yazılımı test etme ile
ya da yazılım ekibindeki Tester arkadaşlarla alakalı olduğunu düşünebilirsiniz fakat gerçekte
geliştirilmiş yazılımı test etmekten ziyade onu geliştirirken kullanılan yöntemidir. Kısaca
tanımlarsak kodu yazmadan önce testlerini yazıyoruz ardından bu testleri geçecek kodu
yazıyoruz.TDD bu şekilde devam eden bir yazılım geliştirme yöntemidir.Bu testleri kim yazacak?
Tabi ki kodu geliştiren yazılımcılar yani biz. Yeni bir fonksiyon ya da geliştirmeyi tanımlamak için
fail eden otomatik test yazma tekniği büyük ya da küçük birçok firmanın sundukları servislerin
kalitesini arttırmak ve geliştirme yapmak için mükemmel yöntemlerden biridir.

3. TDD'nin Tercih Edilmeme
Nedenleri
Test kodu yazmak genelde gereksiz, çok zaman alan, maliyetli ve
öğrenmesi/uygulaması zor olarak görülür. Bu yüzden bir çok kişi/şirket
TDD’den kaçınmayı tercih ediyor. Aslında düşünüldüğünde, TDD
uygulandığında az önce saydığım etkenlerden uzun vadede daha karlı
çıkılacağı artık bilinmeyen birşey değil.
Günümüzde kurumsal projelerin büyük bir bölümü geleneksel yazılım metotları ile
gerçekleştirilmektedir. Müşteri gereksinimleri en son detayına kadar kağıda döküldükten sonra,
programcılar dokumente edilen gereksinimler doğrultusunda yazılımı gerçekleştirmektedirler. Eğer
proje bütçesi yeterli ise, yazılım süreci sona erdikten sonra testler hazırlanarak, yazılım sistemi tes
edilmektedir. çoğu zaman hiçbir unit testin yapılmadığı sistemlerin firmalar tarafından kritik iş
alanlarında kullanıldığını görmek mümkündür. Bu tür yazılım sistemlerinde oluşan hatalar (Bug)
firmanın sunduğu hizmetleri kısıtlamakta ve en kötü ihtimalle firmanın para kaybetmesine sebep
olmaktadır

4. TDD Zaman Kullanimi
''TDD bize zaman kaybettiriyor. Deadline’a yetişmesi
gereken bir sürü iş var.''
Bu anti-TDD’cinin en önemli savunma mekanizmasıdır.
Kendisi bir konuda haklıdır. TDD ile yazdığınız kodun 2-3
katı kadar (belki daha çok) test kodu yazarsınız. Ancak
gözden kaçırdığı ise, kendisinin sadece günü kurtardığıdır.
Yazdığınız kodda değişiklik yaptığınızda diğer parçaların
hala beklenen bir şekilde çalıştığından emin olabilir misiniz?
TDD ile olabilirsiniz. Çünkü her bir birimin kendine özgü testi
vardır. Kod değiştiğinde tek yapmanız gereken daha
önceden hazır olan testleri bir kez daha çalıştırmak. Kısa
vadede günü kurtarıyorsunuz, ancak yazılımınız belki yıllarca
çalışacak.

5. TDD'nin Maddi Acidan Tercih
Edilmeme Nedeni ?
Geleneksel tarzda oluşturulan yazılım sistemlerinde oluşan hataları gidermek çok
pahalıya mal olabilmektedir, çünkü yazılım bittikten sonra tespit edilen hatalar
yazılım sistemindeki tasarım açıklarını gözler önüne serebilir ve bu gibi kardinal
hataların ortadan kaldırılması ya imkansız yada çok zor olabilir. Bunun yanı sıra
yazılım sona erdikten sonra oluşturulan testlerin test kapsama alanı geniş olmadığı
için kodun bazı bölümleri test edilememekte ve böylece hata tespiti zorlaşmaktadır.
Bu şekilde yazılım esnasında ortaya çıkmayan hatalar, daha sonra sistem
kullanıcıları tarafından keşfedilmektedirler. Bu aşamada geç kalınmıştır: ya sistem
çalışmaz durumdadır, yada sistem kullanıcısı istediği işlemi doğru olarak
gerçekleştirememiştir. Durumu kısaca şöyle özetleyebiliriz: “yazılım sistemi
müşterinin gereksinimlerini tatmin edecek kaliteye sahip değildir”.
Ne yazık ki birçok firma için kullandıkları yazılım sistemlerindeki kalite problemleri
firmaya zarar verici durumdadır. Bu kalite problemleri bir taraftan oluşan sistem
hataları, diğer taraftan kodun bakımı ve geliştirilmesinin zor olmasından
kaynaklanmaktadır. Oluşan sistem hataları firmanın giderlerini artırmakta ve yazılım
sisteminin istikrarsız ve güvenilmez olmasına sebep vermektedir. Bu sorunların
temelinde test konseptlerinin bir yazılım sistemi için hayat sigortası olduğunun
anlaşılamamış olması yatmaktadır

6. TDD'nin Bize Getirileri Maddeler Halinde Sunlardir;
●
Sadece ilgili birim testlerin yapılarak kodun güvenli hale getirilmesi.
● Kod tasarımından kaynaklanabilecek problemlerin ortadan kaldırılması.
●
Testlerin bir bütün haline getirilerek, geriye dönük testlerin sürecin önemli bir parçası haline getirilmesi.
● Yeni eklenen kodlar, ya da değiştirilen kodlarda mevcut kodların işlevlerinin bozulmaması.
●
Kodların güvenli ortamda nesneye yönelik tasarı mimarisine uygun üretilmesini azami ölçüde
kolaylaştırması.
●
Kodların dokümantasyon yerine, test senaryolarından daha kolay anlaşılabilir olması.
● Sağlanan güvenli ortam sayesinde, refactoring işlemlerinin güvenli hale getirilmesi.
●
Bug oluşması ihtimalinin azaltılması.
● Her an live ortama geçilebilecek kodların çıkarılması.
●
Gereksiz kod kalabalığının ortadan kaldırılması.
● Test ekibinin gerçek test işlemlerine odaklanmasının sağlanması.
● Proaktif çalışma sayesinde, sıkıcı bir geliştirme ortamı yerine, eğlenceli ve güvenli bir ortamda
motivasyonu yüksek ekiplerin oluşturulabilmesi.

7. TDD'nin Cesitleri
Unit Testing (Birim Testler)
Bir yazılımın her bir biriminin kendine özgü testler ile dışa bağımlı olmadan test edilmesi
anlamına geliyor. Yani bir kullanıcı login mekanizmasını test ediyorsanız, veritabanı ve
cookielere bağlı olmadan kodunuzun beklendiği aşamaları kaydedip kaydetmediğinize
bakıyorsunuz.
Functional Testing (Fonksiyon Testi)
Adından da anlaşılabileceği üzere, bir işlevin gerektiği gibi çalışıp çalışmadığını test
etmemize yarıyor. Az önce unit testte veritabanı ve cookie’ye bağlı olmadan login
mekanizmasını test etmiştik. Functional testler ile veritabanı ile bağlantıya geçtiğinde
gerçekten doğru bir şekilde login olup cookieleri doğru bir şekilde kaydedip
kaydetmediğini de test ediyoruz.

8. Tümleyim Testi (Integration Testing) : Bir uygulamanın farklı bileşenlerinin beraberce
uyum içinde çalışıp çalışmadığını sınamak için yapılan bir testtir. Bileşenler, modüller,
bağımsız uygulamalar, istemci/sunucu uygulamaları biçiminde olabilirler. Bu tür testlere,
özellikle istemci/sunucu uygulamaları ve dağıtık sistemlerin testinde başvurulmaktadır.
Bunun yanısıra uygulamaya yeni işlevsel elemanlar ya da program modülleri eklendikçe
sürekli test edilmesi işlemine de “Artımsal Tümleyim Testi” adı verilir. Test uzmanları
ve/veya programcılar tarafından gerçekleştirilen testlerdir.
Regresyon Testi (Regression Testing) : Uygulamada ve uygulama ortamlarında
gerekli değişiklikler ve sabitlemeler yapıldıktan sonra yeniden yapılan testlere çekilme
(regresyon) testi denilir. Böylece, önceki testlerde belirlenen sorunların giderildiğinden ve
yeni hatalar oluşmadığından emin olunur. Uygulamanın kaç kez yeniden test edilmesi
gerektiğini belirlemek güçtür ve bu nedenle, özellikle uygulama geliştirme döneminin
sonlarına doğru yapılır.
Zorlanım – Performans Testi (Performance Testing) : Bu test, çoğu kez "yük testi" ile
aynı anlamda kullanılmaktadır. Aynı zamanda, beklenmedik (normal olmayan) ağır
yükler, belirli eylemler ve taleplerin çok fazla artışı, çok yoğun sayısal işlemler, çok
karmaşık sorgulamalar vb. ağır koşullar altında olan bir sistemin işlevsellik testi (iş
yapabilme testi) olarak da tanımlanabilmektedir. Bir web sitesi için sistem tepkisinin
hangi noktada azaldığı veya yanıt veremez olduğunu belirlemek için yapılan testler,
performans testine örnek teşkil edebilir.

9. Kullanıcı Kabul Testi (User Acceptance Testing) : Son kullanıcı veya müşteri
siparişine (veya isteklerine) dayanan son test işlemidir. Kullanıcıların, uygulamayı
“kabul” etmeden önce, söz konusu uygulamanın gereksinimlerini ne ölçüde
karşılayıp karşılamadığını belirleyip, geri dönüş yapabileceği testlerdir.
Beyaz Kutu Test Tekniği (White Box Testing Technic) : Beyaz kutu test
tekniğinin en genel tabiri kod testidir. Projenin hem kaynak kodu, hem de derlenmiş
kodu test edilir. Bu tür testler, uygulama kodunun iç mantığı üzerindeki bilgiye
bağlıdır. Yazılım kodundaki deyimler, akış denetimleri, koşullar vb. elemanlar
sınanır.
Kara Kutu Test Tekniği (Black Box Testing Technic ) : Test ekipleri tarafından en
çok kullanılan teknik olan kara kutu test tekniği adından da anlaşılacağı gibi
uygulamanın sadece derlenmiş kodu üzerinden test edilmesi olarak bilinir. Bu test
tekniğinde, yazılımın programatik yapısı, tasarımı veya kodlama tekniği hakkında
herhangi bir bilgi olması gerekli değildir. Yazılımın gereksinimine duyulan şeylere
yanıt verip veremediği ve işlevselliği sınanmaktadır.

15. Giray KÜREKÇİ No : 13125026
Bolum : Bilgisayar Programcılığı