fazlamesai.net'e Soralım: Test Driven Development Hakkında Ne Düşünüyorsunuz?

0
anonim
Aslında uzunca bir süredir haberim var TDD den ancak bir türlü daha ayrıntılı incelemeye fırsat bulamıyordum.

Beni ateşleyen artima.com daki bu makale ona gelen yorumlar oldu. TDD sizce yeni bir yaklaşım mı? Yoksa büyük çaplı projelerde onlarca test yazdıktan sonra detaylı iş tanımları yazmaktan bir farkı yok mu ?

Not: Bu arada makaledeki M$ye ait linkin M$ tarafından sitelerinden kaldırılmış olması bir diğer ilginç nokta...

Görüşler

0
sadettinpolat
tdd yeni bir kavram degil. en az 15 yildir bazi insanlar bunun farkinda ve kullaniyorlar. benim bildigim bunu ilk kullanan insanlardan birisi kent beck. smalltalk ile yazilim gelistirirken tdd yi aktif olarak kullaniyorlarmis. tdd 'nin bana gore cok buyuk iki avantaji var 1: kodu kafaniza gore yazamiyorsunuz. yazdiginiz kod nesneye dayali , moduler ve duzenli olmali aksi takdirde tdd uygulanamiyor 2: yazdiginiz kodun testini cok hizli bir sekilde yine bilgisayar yaptigi icin yapilan her hangi bir duzenlemeden sonra aklinizda "acaba bu degisiklik programin baska bi tarafini bozmus olabilir mi?" sorusu kalmiyor kisaca orta ve buyuk sistemlerde cok gerekli birsey
0
arithm
"Extreme programming" paradigmasında temel alınan bir kavram bu. Önce testler yazılıp sonra kod yazılıyor, kural olarak:

http://www.extremeprogramming.org/rules/unittests.html

Yoksa farklı şeyler mi bunlar?
0
ahmetaa
Test ile ilerlyen ya da "once test" yaklasiminin en buyuk faydasi ozellikle proje ilerleyip surum cikmaya hazir olmaya basladiginda anlasiliyor. Bu asamada klasik programcilarin karsilastigi en buyuk sorun yapilan egisikliklerin proje capindaki islevsel etkisinin kestirilemez olmasi. TDD ile sistemin surekli olarak saglikli oldugundan emin olabiliyorsunuz. bu size projede desgisiklik yapma ya da yapisini gelistirme cesareti"kazandiriyor. Aksi halde kendinizin ya da baskasinin kodu uzerinde degisiklik yapmak istediginizde (ornegin kodu basitlestirme ya da hizlandirma seklinde) "aman abi orasi calisiyor, simdi duzeltecegim derken patlatma" seklinde gelistiricilerin direnci ile karsilasilir (bu kavgalara bile neden olabiliyor). TDD ile kural basit, degisiklik sonrasinda test isliyorsa sorun yok. kimse kodu sahiplenmez. Bu nedenle bilhassa uzun soluklu projelerde (surum sonrasinda bakim gerektiren projeler) TDD kanaatimce hayati bir onem tasiyor. Tabi isin karanlik yani ise testlerin yaziminin sIkici ve kolay olmamasi. Baslangicta size zaman kaybettirdiginden patrona bu yaklasimin faydasini gostermek te sizi zorlayacaktir.
0
lifesdkver0_1
Yalniz sizin bu bahsettiğiniz, direk olarak TDD'nin değil; birim testlerin faydası. Önce kodu yazıp, sonra testini yazın biri de aynı faydayı görebilir.
0
FZ


There is something to be learned from a bugstorm. When meeting with a sudden shower of bugs, you try not to get crazy and debug quickly along thousands of lines of source code. But doing such things as watching for variables, commenting out some parts of code, inserting breakpoints you still get bugs. When you are resolved from the beginning, you will not be perplexed, though you still get the same number of bugs. This understanding extends to every software.


http://qs321.pair.com/~monkads/?node_id=304126
0
yboyacigil

TDD atik geliştirme (agile development) yöntem(leri)inin hüsn-ü kabul görmesinden beridir popüler hale geldi. Geliştirmeye önce test yazarak başlamak ve sadece o testi çalıştıracak kodu yazmak alışılmadık bir yöntem olduğu kadar hedefi net olarak belirleyerek (en azından yazılan testin ihtiyacını karşılayacak kadar net) gereksiz ıvır zıvırlarla kodu şişirmeden yazmayı mümkün kılabilir.

Yani geliştirmeye yön veren şey başlangıçta yazılan test veya testlerin ta kendisi. Başka bir şey değil. Böyle olunca da yazılımda istenen şeyi en iyi şekilde belirlemek için önce testlerin tam olarak belirlenmesi ve hazırlanması gerekiyor. Burada testleri hazırlayan grup geliştirmeyi yapacak olan programcı(lar) olabileceği gibi tamamen ayrı bir takım da olabilir. Hatta yazılım isteklerinin programcının önüne yüzlerce sayfalık dokumanlar veya sınıf, etkileşim, kullanım diyagramları olarak gelmektense bir satırı bile çalışmayacak olan test kodları halinde gelmesi ve programcının yap-boz yapar gibi test kodlarının çalışması için ilgil parçaları (sınıf/metodları) bir araya getirip resmi(programı) oluşturması bile mümkün olabilir. Acaba bu veya benzer şekilde bir istekler analizi yaptıktan sonra tasarımı programcılara alın bu testleri çalıştırın diyen/diyebilecek birileri var mıdır/olmuş mudur?

Ancak bunu yapmanın ne kadar zor ve sıkıntılı olabileceğini de göz ardı etmemek lazım. İşe girişince zamanla istekler değişecek ve testleri tekrar elden geçirmek belki de yeniden yazmak/düzenlemek gerekeecek bu hem test kodlarının hem de o ana kadar yazılmış kodların elden geçirilmesi demek. Gerçi atik geliştirme yapıyorsanız geri besleme ile devamlı olarak bir düzenleme sürecine kendinizi alıştırmanız gerekeceğinden ve kısa adımlarla çalışması olası "release"ler çıkarağınızdan bunun büyük bir sıkıntı getirmemesi gerekir. Bu kültüre alışık olmayanlar için yine de zor. Proje zamanının tuturulamaması riski de taşıyor olması ayrı bir sorun. Fazladan testleri de ikame (maintain) etmek zaman kaybı olarak görülecektir. (Sizin tarafınızdan olmasa da yöneticileriniz tarafından)

Gerçek zamanlı uygulamalar için bu testlerin çalıştırılmasının zorluğu başka bir engel olarak karşınıza çıkabilir. Ama bu zorluktan yalancı nesneler (mock objects) kullanılarak kaçılabilir. Başka bir sorun veri kaynaklarının kullanılması gereken durumlarda ortaya çıkabilir.

Sonuç olarak tam anlamıyla uygulanamasa da test kodlarının geliştirmeyi yönlendirmesi amaca yönelik çalışmak için iyi bir rehber olacaktır. TDD Türkiye'de uygulanabilir mi uygulanırsa başarılı olabilir mi diye soracak olur ve hemen kendim cevap verecek olursam atik geliştirme kültürünü kapmış, iyi programcılardan oluşan küçük ekiplerle bu başarılabilir. Ama genel olarak konuşacak olursam hiç sanmıyorum. Türkiye'de zaten oturmuş bir yazılım sektörü olmadığı gibi ciddi eğitim sorunları ve genel bir yetersizlikle karşı karşıyayız. Daha çok fırın ekmek yememiz lazım.

Eğitim şart! :)

0
anonim
Onceden yazilmis bir koda test yazmayi deneyin. Arkasindan sifirdan test yazip sonra kodunu yazin. Sonra yazdiginiz testlere ve kodlara puan verin.
Kisacasi en dogru yaklasim bunu tecrube etmek olacaktir.
Bir kodun test edilebilirligi onun tasarimi hakkinda sizi bilgilendirecektir.
0
sadettinpolat
once kodu yazip sonra testi yazmayi anliyorum da once testi yazip sonra kodu yazmak meselesi biturlu akima yatmiyor. olmayan seyin testi nasil yazilir ? bu konuda ufak bir aciklama alabilir miyiz?
0
anonim
Ortada implement etmeniz gereken bir kabiliyet var ve bunu bir class'in sorumluluguna vermis durumdasiniz. Bu class size bu kabiliyeti saglamak icin size bir interface sunmali ve bu interface'i kullanidiginizda beklenen bir sonuc olmali. Siz bunu sinayan bir test yaziyorsunuz once. Dogal olarak henuz bir implimentasyon olmadigi icin test gecemiyor ve siz test gecinceye kadar kodlama yapiyorsunuz.
google'da basit bir arama ile buldugum 2 ornek:
Ornek 1
Ornek 2

Not: Konu ile ilgili kitap onerisi -> Test Driven Development: By Example (Kent Beck)
0
anonim
Ben vahşi hayatta uygulamadım ama anladığım kadarı ile aynı projenizde ihtiyaç tanımlar gibi test tanımlıyorsunuz. Yani sonuçta elde etmek istediğiniz değer veya olay belli olduğuna göre bunun doğruluğunu test ediyorsunuz. Daha fazla ayrıntı ve kod örnekleri için google a "test first" yazmanız yeterli olacaktır sanırım.
Görüş belirtmek için giriş yapın...

İlgili Yazılar

Pardus

redogre

Php-Nuke telif hakları

butch

Az önce aşağıdaki metni içeren bir mail aldım. Sanırım birisi bizimle dalga geçiyor ama haklı olduğu bir konu var, o da yazılım sahibinin taleplerine mümkün olduğunca saygılı olmak. Ben de Basit kullananların copyright mesajını korumalarına sevinirdim.

KnoppixCD ve Linux El Kitabı PC World Kasım`da

PCW

Daha önce FM'de hakkında çok şeyler yazılıp çizilen Knoppix dağıtımını tam sürüm olarak bu ay, yani PC WORLD'ün Kasım-2002 sayısına yetiştirmeyi başardık. Ayrıca Sundance'in çok özel katkılarıyla hazırladığımız "Linux El Kitabı"nı da beğeneceğinizi umuyoruz. Her türlü görüş, öneri ve eleştirilerinizi bekliyoruz.

Başarılı bir açık kod programcısının maddi durumu

FZ

"I didn't have the money to buy a new laptop"
Yukarıdaki cümle genç bir çocuğa ait değil. Yukarıdaki cümle genç bir üniversite öğrencisine de ait değil. Yukarıdaki cümle sıradan bir programcıya ait değil. Yukarıdaki cümle başarısız ya da meşhur olmayan bir programcıya da ait değil.

Cümle, yaklaşık 15 yıl önce Perl programlama dilini yaratan karizmatik programcı ve dilbilimci Larry Wall´a ait. Bu programcının geliştirdiği Perl programlama dili sözlük hazırlama esnasında yine bu programlama dilinden faydalanan Oxford resmi İngilizce sözlüğe girdi. Onbinlerce sistem yönetim yazılımında kullanıldı. Yüzbinlerce web sitesi Perl kullanarak iş güç yaptı ve yapmaya devam ediyor. Perl son zamanlarda moleküler biyoloji alanında veri işleme için de kullanılıyor. Söz konusu adam işte bu dili geliştirmiş ve Linus Torvalds henüz lisede okurken insanlık kültürüne armağan etmiş olan adam. Bu adam şimdi yeni bir efsaneye, Perl 6´ya imza atmaya çalışıyor. Geliştirdiği Perl açık kodlu, karşılığında 5 kuruş istenmiyor ve aklınıza gelen hemen her işletim sisteminde çalışıyor. Böyle bir adamdan bahsediyoruz yani.

Bu adam, yeni bir dizüstü bilgisayar alacak kadar parası olmadığını söylüyor.

Şaşırdım mı? Evet. Şaşırdım mı? Hayır.

Larry Wall, efsanevi State of The Onion sunularının sonuncusunda, 4. sayfada bu yazının açılış cümlesini sarf ediyor.

Ne dersiniz? Sizce bu adam zor durumda mı? ;-)

Hani gündemdeki popüler konulardandır, "ya hoca biz şimdi bu kodları açarsak aç kalmaz mıyız yaa?" falan denir. Bunu diyenler muhtemelen Larry Wall kadar çok ve kaliteli kod üretmemişlerdir. Acaba diyorum şimdi Larry Wall gerçekten de acınası durumda mı? Başka bir perspektif: Daha çok kazanmak varken neden daha az kazanalım? Sahi, Larry Wall, bir dönem NASA için çalışmak dururken acaba daha bol paralı bir işe mi girseydi? Aklıma Once Upon A Time In China filmindeki bir sahne geliyor. Yağmurlu bir ortamda canını dişine takarak gösteri yapan ve sonra yere atılan paraları toplayan bir kung-fu, demir gömlek ustası. Bir süre sonra aynı usta çetin bir kavgada kılıçlı bir adamı silah kullanmadan yendikten sonra bir genç yanına gelip "usta bana da öğret, zor durumdayım, bana saldırıyorlar, artık para bile kazanamıyorum," der. Usta önce biraz ilerideki lokantadaki lezzetli yemeklere yutkunarak bakar, acı acı gülümseyip cevap verir: "Kung-fu ustası olsan ne olur ki, ben de pek para kazanamıyorum".

Sanırım en temel kavramların yeniden düşünülmeye ve irdelenmeye ihtiyacı var; sanırım felsefeye keyfi yerinde, sadece entelektüel olarak huzursuz olan insanların değil asıl ciddi anlamda zor durumda olan insanların ve belki de en çok gençlerin ihtiyacı var. Sanırım büyük adamlar küçük adamların bazı temel kavramları yeniden düşünmelerini istemiyor. Sanırım bu isteklerini gerçekleştirmeleri sahip oldukları muhteşem güce rağmen yine de kolay olmayacak. Ne dersiniz? Şimdi biz bu kodları kapayıp da mı saklasak yoksa açıp da mı saklasak? ;-)

Sundance de Apple'a geçti - 1

sundance

Geçtiğimiz haftalarda Linus Tornvalds'ın artık Apple tabanlı bir laptop kullanmaya başladığını haber yapmıştık. Bu ayın başında meşhur Lisp hackerı Paul Graham da Mac'in Dönüşü makalesinde ibook ve powerbookların hacker camiasında popülaritesinin artmasından bahsetmişti.

Uzun zamandır 12inch ufak tefek bir laptop almayı planlıyordum, i386'mı olsun yoksa powerpc'mi diye düşünürken, bir arkadaşımın G3 ibook'unu satmaya karar verdiğini duyunca harekete geçtim. Bu makale i386'dan powerpc'e geçişde ne gibi kolaylıklar ve zorluklar yaşadığımın iki bölümlük hikayesidir.