Comments on: Test Driven Development http://www.cihataltuntas.com/?p=37 Test Infected Software Engineer Mon, 06 Sep 2010 23:45:20 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Mesut HAZEN » Blog Archive » Test Driven Development http://www.cihataltuntas.com/?p=37&cpage=1#comment-9857 Mesut HAZEN » Blog Archive » Test Driven Development Sun, 15 Aug 2010 09:41:07 +0000 http://www.cihataltuntas.com/?p=37#comment-9857 [...] view source [...] [...] view source [...]

]]> By: » TDD : Mocks, Stubs and Two Smoking Barrels http://www.cihataltuntas.com/?p=37&cpage=1#comment-7605 » TDD : Mocks, Stubs and Two Smoking Barrels Tue, 04 May 2010 19:06:53 +0000 http://www.cihataltuntas.com/?p=37#comment-7605 [...] Driven Development nedir, ne değildir?”in temel felsefesine daha önceden bu yazıda değinmiştik. Şimdi biraz daha derinlere inip gerçek hayatta TDD ile geliştirdiğimiz [...] [...] Driven Development nedir, ne değildir?”in temel felsefesine daha önceden bu yazıda değinmiştik. Şimdi biraz daha derinlere inip gerçek hayatta TDD ile geliştirdiğimiz [...]

]]> By: Emre http://www.cihataltuntas.com/?p=37&cpage=1#comment-5917 Emre Sat, 26 Dec 2009 14:20:25 +0000 http://www.cihataltuntas.com/?p=37#comment-5917 Makale Gerçekten yararlı olmuş ,aslında yazarken biz bunları zaten biliyoruz çalışır hertürlü diyoruz ve burda hata yapıyoruz..Ekleme güncelleme silme metotları yazarken örneğin bu ekler günceller siler şimdi zaman kaybetmiyeyim daha çok iş var deip geçiyoruz bu aşamayı ve sonra hata çıktığında bunu proje ilerlediğinde analiz etmek bulmak ve halletmek uzun zaman kayıplarını doğurabiliyor..Umarım herkez dikkat eder bu hususa da ..Makale için teşekkrler,Ellerinize sağlık .. Makale Gerçekten yararlı olmuş ,aslında yazarken biz bunları zaten biliyoruz çalışır hertürlü diyoruz ve burda hata yapıyoruz..Ekleme güncelleme silme metotları yazarken örneğin bu ekler günceller siler şimdi zaman kaybetmiyeyim daha çok iş var deip geçiyoruz bu aşamayı ve sonra hata çıktığında bunu proje ilerlediğinde analiz etmek bulmak ve halletmek uzun zaman kayıplarını doğurabiliyor..Umarım herkez dikkat eder bu hususa da ..Makale için teşekkrler,Ellerinize sağlık ..

]]> By: ümran kamar http://www.cihataltuntas.com/?p=37&cpage=1#comment-5506 ümran kamar Wed, 25 Nov 2009 19:13:39 +0000 http://www.cihataltuntas.com/?p=37#comment-5506 Ben de okudum faydalandım, teşekkür edeyim. Maalesef ben de özellikle de bilmediğim bir alana hizmeten program geliştirdiğim için iş hayatımda bu şekilde geliştirme yapamıyorum. Ben de okudum faydalandım, teşekkür edeyim. Maalesef ben de özellikle de bilmediğim bir alana hizmeten program geliştirdiğim için iş hayatımda bu şekilde geliştirme yapamıyorum.

]]> By: Mustafa Tanış http://www.cihataltuntas.com/?p=37&cpage=1#comment-5269 Mustafa Tanış Tue, 27 Oct 2009 09:39:57 +0000 http://www.cihataltuntas.com/?p=37#comment-5269 teşekkürler çok faydalı olmuş teşekkürler çok faydalı olmuş

]]> By: Çağrı Genç http://www.cihataltuntas.com/?p=37&cpage=1#comment-5115 Çağrı Genç Wed, 30 Sep 2009 23:00:17 +0000 http://www.cihataltuntas.com/?p=37#comment-5115 Teşekkürler, çok güzel ve anlaşılır bir makale olmuş. İyi çalışmalar. Teşekkürler, çok güzel ve anlaşılır bir makale olmuş.
İyi çalışmalar.

]]> By: M. Cihat Altuntaş http://www.cihataltuntas.com/?p=37&cpage=1#comment-570 M. Cihat Altuntaş Fri, 13 Mar 2009 15:15:44 +0000 http://www.cihataltuntas.com/?p=37#comment-570 Evet güzel bir soru :) Bilmediğiniz bir iş mantığı için test yazmanın pek mümkün olduğunu düşünmüyorum açıkçası. Testleri yazarkende elimizde belirli gereksinimler olmak zorunda . Eğer iş mantığını biliyorsak fakat sınıflarda neleri test edeceğimizi bilmiyorsak burada biraz OOP kuralları, biraz içgüdü işin içine giriyor.Doğaçlama yazsanız bile daha sonradan Refactoring ile testleri değiştirip sınıflar arası sorumlulukları taşıyabilirsiniz. Bende toparlarsam yazacağınız uygulamada TDD olsun ya da olmasın, iş mantığını,gereksinimleri bilmeniz gerekiyor. Eğer bilmezseniz aynı kodu,testi sürekli değiştirmek zorunda kalırsınız..... Evet güzel bir soru :) Bilmediğiniz bir iş mantığı için test yazmanın pek mümkün olduğunu düşünmüyorum açıkçası. Testleri yazarkende elimizde belirli gereksinimler olmak zorunda . Eğer iş mantığını biliyorsak fakat sınıflarda neleri test edeceğimizi bilmiyorsak burada biraz OOP kuralları, biraz içgüdü işin içine giriyor.Doğaçlama yazsanız bile daha sonradan Refactoring ile testleri değiştirip sınıflar arası sorumlulukları taşıyabilirsiniz.

Bende toparlarsam yazacağınız uygulamada TDD olsun ya da olmasın, iş mantığını,gereksinimleri bilmeniz gerekiyor. Eğer bilmezseniz aynı kodu,testi sürekli değiştirmek zorunda kalırsınız…..

]]> By: Volkan http://www.cihataltuntas.com/?p=37&cpage=1#comment-568 Volkan Fri, 13 Mar 2009 15:00:19 +0000 http://www.cihataltuntas.com/?p=37#comment-568 Elinize sağlık. (Forumlardaki gibi oldu ama :) ) Verdiğiniz örnek basit bir program ve bildiğimiz kurallar doğrultusunda test yazdınız. Eğer tam anlamıyla hakim olmadığımız bir konuda program yazıyorsak bu testin başarısı ne olur?? Çünkü sondan başa doğru gittiğimiz kesin. Önce hataları düşünüyoruz daha sonra programa uyguluyoruz. Eğer bilmediğimiz bir konu için örneğin iş mantığı için kod yazdığımızı varsayalım. Belli genel kontroller (null excp gibi) dışında iş mantığı kontrollerinde sorun oluşur mu? Toparlarsak bu testleri yazmak için konuya hakim olmamız gerekmez mi? Elinize sağlık. (Forumlardaki gibi oldu ama :) ) Verdiğiniz örnek basit bir program ve bildiğimiz kurallar doğrultusunda test yazdınız. Eğer tam anlamıyla hakim olmadığımız bir konuda program yazıyorsak bu testin başarısı ne olur?? Çünkü sondan başa doğru gittiğimiz kesin. Önce hataları düşünüyoruz daha sonra programa uyguluyoruz. Eğer bilmediğimiz bir konu için örneğin iş mantığı için kod yazdığımızı varsayalım. Belli genel kontroller (null excp gibi) dışında iş mantığı kontrollerinde sorun oluşur mu? Toparlarsak bu testleri yazmak için konuya hakim olmamız gerekmez mi?

]]> By: M. Cihat Altuntaş http://www.cihataltuntas.com/?p=37&cpage=1#comment-426 M. Cihat Altuntaş Wed, 04 Feb 2009 08:16:20 +0000 http://www.cihataltuntas.com/?p=37#comment-426 Eğer test ettiğiniz methodun verdiğiniz parametrede Exception fırlatıp fırlatmadığını kontrol etmek istiyorsanız zaten Test metodlarının üstünde bunu @Test(expected = IllegalArgumentException.class) şeklinde belirtiyorsunuz. Yani aynı işi yaptığı için Assert yapmanıza gerek yok.Fakat oraya Assert yazsanızda durum değişmeyecek. Birazda tercihinize bağlı diyebilirim. Eğer test ettiğiniz methodun verdiğiniz parametrede Exception fırlatıp fırlatmadığını kontrol etmek istiyorsanız zaten Test metodlarının üstünde bunu @Test(expected = IllegalArgumentException.class) şeklinde belirtiyorsunuz.

Yani aynı işi yaptığı için Assert yapmanıza gerek yok.Fakat oraya Assert yazsanızda durum değişmeyecek. Birazda tercihinize bağlı diyebilirim.

]]> By: whitestream http://www.cihataltuntas.com/?p=37&cpage=1#comment-425 whitestream Wed, 04 Feb 2009 08:10:15 +0000 http://www.cihataltuntas.com/?p=37#comment-425 Exception fırlatan test method larında, Test frameworklerin kullanmak iyi bir alışkanlık olurmu (Assert gibi)? Exception fırlatan test method larında, Test frameworklerin kullanmak iyi bir alışkanlık olurmu (Assert gibi)?

]]>