Ne Zaman Test Güdümlü Yazılım Yapmalıyım? başlıklı yazım.
Kategori arşivi: Test Driven Development
Test Güdümlü Yazılımın Tasarım Üzerindeki Etkileri
Yazılımcı olarak çalıştığım projelerde geleneksel ve çevik yazılım süreçleri hakkında tecrübe edinme firsatı buldum. En son kitabım bir çevik süreç olan Extreme Programming hakkındadır. Edindiğim tecrübeler doğrultusunda çevik süreçlerin, klasik yazılım süreçlerine nazaran bakımı ve geliştirilmesi daha kolay yazılım sistemlerinin oluşturulmasında daha avantajlı olduğunu söyleyebilirim.
Bu yazımda sizelere test güdümlü yazılım sürecinin, yazılım tasarımı üzerindeki etkilerini bir örnek üzerinde aktarmak istiyorum. TDD ile birlikte oluşan tasarım, kendiliğinden oluşan birşey değildir. Testler şekil aldıkça, oluşturmak istediğimiz tasarımın modeli de gözümüzde canlanmaya başlar. Oluşturduğumuz testler, programın gelecekteki kullanıcılarını (client) simule ettiği için, programın nasıl kullanılacağını testler bünyesinde gözlemlemek kolaylaşmaktadır. Bu süreç, sınıfların ve metotların kullanıcı gözüyle (client) tasarlanmasını sağlar. Bu sayede basit ve kullanışlı API (Application Programming Interface)’ler oluşur. Test güdümlü yazılım tasarımı devamlı zorlar ve yetersiz kaldığı yerlerde refactoring yöntemleriyle yenilenmesini sağlar. Bu süreç sayesinde kendisini devamlı yenileyen ve yeni gereksinimlere cevap veren bir tasarım oluşur.
Bu yazıyı PDF olarak edinebilirsiniz.
Test Güdümlü Yazılımın Tasarım Üzerindeki Etkileri (183,5 KiB, 8.158 yükleme)
EOF (End of Fun)
Özcan Acar
Test Güdümlü Yazılım – Test Driven Development (TDD)
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 test 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.
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.
Test Güdümlü Yazılım - Test Driven Development (TDD) (416,9 KiB, 10.438 yükleme)