Monthly Archives: August 2007

UNIT TESTING & TDD (Test Driven Development)

Geçtiğimiz haftadan bu yana üzerinde çalıştığımız projenin test aşamasını iyileştirebilmek (yada gerçekleştirebilmek) adınatest.jpg Unit Testing ve Test Driven Development ile ilgili araştırmalar yapıyorum. Bu süreçte bir yandan birşeyler öğrenme bir yandan da bu öğrendiklerimi hali hazırda yürüttüğümüz projeye uygulama şansına sahibim. Bu nedenlerden ötürü geçtiğimiz haftayı Unit Testing ve Test Driven Development üzerinde araştırma yaparak geçirdim. Bu noktada bana düşen en önemli görev developer arkadaşları Unit Test yazmanın bir lüks değil bir gereklilik olduğuna ikna etmek. O nedenle bu gerekliliğe kendimi iyice inandırmaya çalıştım ve yüzlerce linki , yazıyı taradım. Bu süreçte öğrendiklerimi belirli başlıklar altında sizlere paylaşmak güzel olacaktır diye düşündüm.

(NOT: Test-Driven Development = Test Güdümlü Yazılım Geliştirme ,Unit Test= Birim Testi olarak kullanılacaktır.)

Test Güdümlü Yazılım Geliştirme Nedir?

Test Güdümlü Yazılım Geliştirme: önce gerekli test koşullarını yazıp ardında da bu testleri geçecek ve hedeflenen işi yapacak kodu yazmayı öngören bir yazılım geliştirme modelidir.

Bu yazılım geliştirme modeli dahilinde aşağıdaki adımlar izlenir:

• Öncelikle yazılımın ilgili birimi için basitçe bir test yazılır.
• Bir sonraki adımda teste tabi tutulacak birim yazılır.
• Eğer o birim, testi geçerse test geliştirilir ve birim tekrardan test edilir.
• Eğer birim testi geçemezse gerekli değişiklik yapılır ve tekrar test edilir.
• Birim son halini alana kadar her değişiklikte test edilir.
• Birim beklenen işi gerçekleştiriyorsa ve tüm testleri geçiyorsa süreç tamamlanır.

Test Güdümlü Yazılım Geliştirme , geliştirme sürecimizi hem hızlandırır hem de iyileştirir çünkü yazılan kodların bir hata durumunda tekrardan yazılması veya hatanın bulunmaya çalışılması ciddi bir maliyet oluşturur.
Test Güdümlü Yazılım Geliştirme yöntemi bir Sürüm Yönetim Sistemiyle birlikte kullanılırsa çok daha verimli olacaktır çünkü bu yaklaşım hata durumunda tüm testleri geçen sürüme geri dönülmesi kolaylığını getirir ve de kodun içerisinden hata ayıklamaktan daha efektiftir.

Birim Testi Nedir?

Birim Testi yazılım projemizdeki her bir birimin (Object-Oriented Programming çerçevesinde en küçük birim sınıftır) doğru bir şekilde çalışıp çalışmadığını anlamak amacıyla oluşturduğumuz testtir.

Birim testi hem Test Güdümlü Yazılım Geliştirme Sürecini kolaylaştırır hem de uygulamamızın her bir biriminin sorunsuzca çalıştığından emin olmamızı sağlar.

Neden Önce Birim Testi Yazılmalıdır ? (Test-First Approach)

Yazılım geliştiriciler için Birim Testi yazmanın yada Test Güdümlü Yazılım Geliştirme Süreci ‘ne adapte olmanın en zor noktası henüz yazılmamış bir birim için test yazmaktır. Bu noktada alışkanlıkların değiştirilmesi biraz zaman alabilir.

Testi , işi yapacak birimden önce yazmamızın nedeni: testi yazabilmek için o teste tabi tutulacak birimin ne iş yapacağını iyice anlamamızı gerektirmesidir. Eğer ilgili birimin verilen giriş bilgisine karşılık çıkışta ne üreteceğini iyice anlamışsak ancak o koşulda testini yazabiliriz. Testi yazdıktan sonra da o testi geçecek kodu yazmak daha kolay olacaktır çünkü testin yazımı sırasında o birimin yapacağı iş kafanızda netleşmiş olur.

Birim testini önce yazmak konusunda yapılan en büyük hata; ilk seferde doğru testi ve bu teste uygun birimi yazmayı hedeflemektir. İlk başta hem test hem de teste tabi tutulacak birimde hatalar ve eksiklikler olabilir fakat test ve düzeltme süreci yukarıda bahsedildiği şekilde tekrarlandıkça bu süreç sonunda ortaya daha kaliteli ve daha güvenilir bir ürün ortaya çıkacaktır.

Birim Testini Projemdeki Hangi Bileşenler İçin Yazmalıyım?

Bu noktada karar uygulama geliştiriciye aittir. Fakat Nesne Yönelimli Programlamada genel yaklaşım bir sınıf içerisindeki tüm public metodlar için birim testi yazmak yönündedir.

Öte yandan değişkenlere erişimi düzenlemek amaçıyla kullandığımız (Accessors- Mutators) metodlar ve bir bakışta işlevi anlaşılıp hata olduğunda kolaylıkla bulunabilecek metodlar için birim testi yazılmayabilir.

Tüm metodlar için birim testi yazmamanın tek dezavantajı projemizin Code Coverage (Code Coverage:Bir projedeki test edilen kodların, tüm kodlara oranı ) yüzdesini düşürmesidir.

Birim Testi ile İşlevsellik Testi (Functional Test) Arasındaki Temel Fark Nedir?

Birim Testi uygulama geliştiricinin kendi perspektifinden, yazdığı kodun doğru çalışıp çalışmadığından emin olmak amacıyla yapılırken , İşlevsellik Testi kullanıcının perspektifinden bakılarak yazılan kodun kullanıcı ihtiyaçlarını karşılayıp karşılamadığını tespit etmek amcıyla yapılır.

Birim Testi kod yazımından önce yapılırken , İşlevsellik Testi ürün müşteriye verilmeden evvel yapılır.

Birim Testinin Yazılım Geliştirme Sürecine Katkıları Nelerdir?

• Refactoring işlemlerini kolaylaştırır: Tüm birim testlerden başarıyla geçmiş bir kod bloğu üzerinde refactoring yaptığınızda kodunuzun bozulup bozulmadığını birim testini tekrar çalıştırarak rahatlıkla anlayabilirsiniz.
• Sonradan ortaya çıkabilecek hataların oluşturacağı maliyeti en aza indirir.
• Yazılımış kodları inceleme (Code Inspection) işleminden daha kolay ve daha verimlidir.
• Uzun vadede testsiz kod yazmaktan daha hızlı kod yazmayı sağlar çünkü aynı kodların hata durumunda tekrardan düzenlenmesi ihtiyacını en aza indirger.
• Birim testi yazmak, bizleri yazacağımız kodun işlevini en ufak detayıyla anlayama iter çünkü işlevini tam olarak anlayamadığımız bir birimin testini yazma şansımız yoktur. Bu da yazılan birimlerin daha doğru olmasını sağlar.
• Yazılan kodlar için bir çeşit dökümantasyon sağlar çünkü yazılan test koşulları incelenerek o kod bloğunun işlevi rahatlıkla anlaşılabilir.

Yukarıda bahsi geçen konularla ilgili öğrenme sürecim hala sürüyor o nedenle blogumda bu konuyla ilgili paylaşımlara devam edeceğim. Kısa bir süre içinde bu konuyla ilgili faydalanabileceğiniz linkleri kategorize ederek sizlerle paylaşmayı planlıyorum. Şimdilik benden bu kadar. Bir sonraki yazıma kadar sağlıcakla kalın…

NOT: Bu gece 3 gün sürecek ufak bir İzmir tatiline çakacağım. Umarım orada da blogumu güncellemeye fırsatım olur?

UYUMSUZLUĞA MICROSOFT ‘TAN ÇÖZÜM GELDİ

Internet Explorer 7 ‘ye geçiş sırasında ciddi problemler yaşanlardan biriyim ben de. Neyseki artık hayatımda IE ‘nin pek bir yeri kalmadı. Fakat bu durum herkes için geçerli değil elbette. Israrlı ve sadık Microsoft kullanıcıları hala IE kullanmaktan bir türlü vazgeçmiyorlar. (İşletim sistemine entegre olarak gelmenin avantajı böyle birşey olsa gerek) Microsoft da bu arkadaşları düşünerek User Agent String Utility v2.0 adlı aracını geçtiğimiz hafta yayınladı.

Bu araç sayesinde henüz IE 7 ‘ye adapte olamamış sitelere kendinizi farklı bir tarayıcından geliyormuş gibi gösterip bağlanqbiliyorsunuz. (Daha doğrusu daha düzgün görüntülüyebilemenizi sağlıyor) Bu ufak uygulamayı kurduktan sonra masaüstünüze oluşturacağı kısayol yardımıyla Internet Explorer ‘ı farklı bir User Agent bilgisiyle açabilirsiniz. Sisteme herhangi bir kayıt eklemieyen bu uygulamaın oluşturduğu kimlik sadece masaüstünüzdeki kısayol ile açtığınız pencere için geçerli oluyor.

Eğer Internet Explorer ‘a kalıcı olarak bu profili vermek istiyorsanız http://www.enhanceie.com/useragent.aspx adresindeki registry scriplerden faydalanabilirsiniz. EricLaw tarafından hazırlanan sitede Internet Explorer kullanıcılarının işine yarayabilecek çok faydalı scriptler ve eklentiler mevcut.

Microsoft ‘un bu tip bir araç çıkarması bana Microsoft MVP olan bir arkdaşım söylemiş olduğu: “Microsoft geriye uyumluluk konusunda dünyanın en iyi firmasıdır.” cümlesini hatırlattı. Geriye uyumluluk bu mudur , böyle birşey midir? Uydurmacılık nedir peki?…

user_agent.jpg

SEMİNER DUYURUSU (İnternet Teknolojilerinin Dünü, Bugünü ve Yarını)

Geçtiğimiz haftasonu gerçekleştirdiğimiz .NET ve Yeni Mcirosoft Teknolojileri konulu seminerin ardın, CETURK olarak 8 Eylül ‘de bir seminer daha gerçekleştireceğiz. Bu defa konuşmacı olarak Ali Rıza BABAOĞLAN bizlerle birlikte olacak. Byte Türkiye ‘de İnternet editörü olan Ali Rıza bizlerle bu konudaki birikimini paylaşacak. Seminer geçmişten bu güne internetin ve alışkanlıklarımızın değişimini içerecek. Özellikle de Alı Rıza ‘nın Web 3.0 konusundaki paylaşımlarını ben de merak ediyorum. (Semantik web ve OWL ile hayat nasıl olacak ben de merak ediyorum) Etkinlikle ilgili detaylar aşağıda. Seminerde görüşmek dileğiyle…

ETKİNLİK DETAYLARI
Etkinlik Konusu : İnternet Teknolojilerinin Dünü, Bugünü ve Yarını
Etkinlik Türü : Seminer
Hedef Kitle : Web Tabanlı Uygulama Geliştirenler, Öğrenciler
Kontenjan : 80
Etkinlik Tarihi – Saati : 08.09.2007 — 14.00 – 16.00
Süre : 1 Gün
Eğitimi Veren : Ali Rıza BABAOĞLAN
Etkinlik Yeri : Microsoft Türkiye İletişim Bilgileri
ETKINLIK IÇERİĞİ
Web 1.0 Ne İdi?Web 2.0 Neler Sundu?Web 3.0 Neler Sunacak?
KONUŞMACI
Byte Türkiye’de İnternet Editörü olarak çalışmakta olan Ali Rıza Babaoğlan, web tabanlı teknolojileri ve web tabanlı uygulama geliştirme alanında çalışmalarını sürdürmektedir. Ali Rıza Babaoğlan hakkında daha detaylı bilgiye bu adresden erişebilirsiniz.
ETKİNLİK SPONSORUMUZ
ETKİNLİK HEDİYEMİZ
Seminere katılan 3 üyemize çekilişle aşağıdaki kitaplardan hediye edilecektir.:

CEVABI KİM BİLİYOR?

word.pngCuma günü Erhan Burhan ‘dan gelen e-mail aracılığıyla WordPress ve altındaki tüm blogların erişime kapatıldığını öğrenmiştim. Türk Telekom ‘un DNS ‘ini kullanmadığım için durumu fark edememişim haliyle. Bundan ötürü abartıp Erhan ‘dan bir ekran görüntüsü bile istemiştim. (Gözümle görmeden inanmam dercesine)

Haftasonu bu erişm engelleme kararı tüm WordPress camiasının gündemindeydi. Ne oldu , ne olacak , nasıl kurtuluruz bu durumdan şeklinde sorular , erişim izninin çıkmasıyla son buldu. (Temizlenmeyen DNS cacheler yüzünden bazılarımız için bu sorular biraz daha uzun sürdü.)

Bugün de WordPress ‘in geliştiricilerinden Matt bu erişim yasağı ile ilgili olarak kendisine ulaştırılan açıklama metnini bloguna taşımış. İşin ilginç tarafı da o da ne yapacağını bilemeyip Türk kullanıcılara “ne desek” diye sormuş.

I’m curious, particularly amoung our Turkish community, what do you think we should do about this? How should we respond?

Buradaki metinde geçen “Biz size defalarca söyledik ama dikkate almadınız yada herhangi bir geri dönüş yapmadınız” şeklindeki imalar beni çok şaşırttı. Çünkü ben WordPress ile ne zaman iletişime geçsem mutlaka bir cevap alıyorum .Ya Matt yada Mark mutlaka bir cevap dönüyorlar. Böyle bir durumun ortaya çıkmış olması çok garip. Elbette kendilerine bu tip bir rapor olaşıp ulaşmadığını ancak WordPress ekibi bilir ve belki de bu durumla ilgili bir açıklama yaparlar. (En azından ben kendilerine bu soruyu sordum)

Sonuç olarak hiç de hoş olmayan ve itibarımızı zedeleyecek bir durumla karşı karşıya kaldık. İşin kötüsü bu durum karşında ne yapacağız sorunun cevabını WordPress ekibi de bilmiyor. Ee peki o zaman cevabı kim biliyor?