Son zamanlarda iyice popülerliği artan test driven development (test tabanlı geliştirme) konusunda birkaç yazı yazmak istedim. Öncelikle test driven development’ın ne olduğu ile başlamak istiyorum.
Nedir?
TDD geliştirilen veya geliştirilecek yazılımın otomatikleştirilmiş testlerinin yapılarak uygulanan bir yazılım geliştirme şeklidir. Otomatikleştirilmiş testler bir kez hazırlanır ve istenildiği zaman tekrar tekrar çalıştırılabilir. Bu şekilde kodun bir parçası değiştiğinde diğer parçaların ondan etkilenip etkinlemediğinden her seferinde emin olabiliyoruz. Otomatikleştirilmiş testlerin en basiti mouse ve klavye hareketlerini kaydederek tekrar tekrar yazılım üzerinde uygulamaktır. Mouse ve klavye hareketlerini bir kez kaydederek her seferinde tüm parçaları tek tek elle test etmek zorunda kalmıyoruz. Tabiki bu mouse, klavye hareketlerini kaydetmek çok antik bir yöntem. Elbette biz bunu yapmayacağız. Ancak otomatikleştirilmiş testlere en basit örnek budur demek istedim.
Neden?
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.
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.
Öğrenmesi/Uygulaması zor
Zor mor değil. 200-300 sayfalık bir kitap okuyarak veya sağdan soldan blog postları okuyarak, deneyerek uygulayabilirsiniz. Mükemmel bir şekilde uygulayamasanız bile, test edilmemiş bir yazılımdan her zaman daha iyidir.
Değişimlere ayak uydurmak
Herkes bilir ki bir yazılım projesi asla bitmez. Ürün sahibi her zaman yeni isteklerde bulunur. Bunlara yazılımcı her zaman itiraz/küfür eder. Yinede seve seve yapmak zorunda kalır. Ancak yazılımcı artık değişimlerin kaçınılmaz olduğunun farkında olması gerekir. TDD yaparak değişimlere çok iyi bir şekilde ayak uydurabilirsiniz. Yazılım her ne kadar değişsede siz zaten önceden yazdığınız testler ile buna hazırsınız. Hala yazılımınız güvenilir bir şekilde çalıştığından eminsiniz. Test edilebilir bir kod ürettiğinizde kodunuz zaten istemeseniz bile değişimlere kolay ayak uydurabilen bir kod olmuş oluyor.
Nasıl?
TDD içerisinde bir çok test çeşidini barındırıyor.
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.
Acceptence Testing (Kabul edilebilirlik Testi)
Burada ise, sizin yazdığınız yazılımın, sizden istenenleri gerçekten karşılayıp karşılamadığını test ediyorsunuz. Mesela bir acceptence test:
– Login olmak istiyorum
– Kullanıcı adım: test
– Şifrem: test
– Login buttonuna basıyorum
– Login olmuş olmalıyım
Burada yazanları bir kod olarak yazıyorsunuz. Ve istekler ile sizin yazılımınızın uyuşup uyuşmadığına bakıyoruz.
Sonuç
Bu yazı ile TDD’ye teorik olarak bir göz atmış olduk. Bir sonraki yazımda ise PHP ile TDD hakkında birkaç şey yazacağım. Hepinize kolay gelsin.
This entry was posted in Genel and tagged acceptence testing, black-box testing, functional testing, tdd, test driven development, unit testing, white-box testing on 17 October, 2013 by Can Geliş.	
Post navigation
← Responsive Design – 2 Media Queries PHP ve TDD: PHPUnit Nasıl Kullanılır? →
Leave a Reply Cancel reply
Your email address will not be published. Required fields are marked *
To create code blocks or other preformatted text, indent by four spaces:
    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)
To create not a block, but an inline code span, use backticks:
Here is some inline `code`.
For more help see http://daringfireball.net/projects/markdown/syntax
Comment
Name *
Email *
Website
Arama
Search for:
Son gönderiler
Git ile Açık Kaynaklı Projelere Katkıda Bulunmak
Laravel: Facade olmayan Facadelar
Takım Halinde Kod Geliştirmek – Git Workflow
CentOS Sunucumuza VPN Server Kuruyoruz
Laravel 4 Pagination HTMLi Özelleştirme
Son yorumlar
emre on Git ile Açık Kaynaklı Projelere Katkıda Bulunmak
Gökhan on Takım Halinde Kod Geliştirmek – Git Workflow
David Baldwin on Laravel 4 Pagination HTMLi Özelleştirme
Samet Erdem on PHP: Composer Nedir? Nasıl Kullanılır?
crazy bw on Takım Halinde Kod Geliştirmek – Git Workflow
Kategoriler
CSS
Genel
Git
JavaScript
JQuery
Linux
Object Oriented Programming
PHP
Etiket bulutu
alert alert değiştirmek autoload açık kaynak block classloader comet composer composer.json composer.phar css css3 design patterns display git güvenlik html5 inline inline-block javascript jquery kaliteli kod kütüphane laravel mysql mysqli nesneye yönelimli programlama object-oriented programming oop open source pdo php phpunit prepared statements psr-0 responsive design singleton pattern solid spl_autoload_register table table-cell tdd test driven development test edilebilir kod unit testing