Ana içeriğe atla

Kayıtlar

TDD etiketine sahip yayınlar gösteriliyor

Test Attributes (TDD, Birim Testleri)

Bu yazımızda Test Driven Development (TDD) , Unit Test ve Test Projesi Oluşturma makalelerinin ardından bazı test attribute’ların neler olduğuna değinilecektir. Test Attribute’lar test methodlarının başlarında yer alır ve ilgili metodu özelleştirmek için kullanılır. Bazı attribute’lar Test Projesinin tamamında etkili olmak üzere kullanılırlar. Test Attributes AssemblyInitialize: Assembly tarafından tahsis edilen kaynakların yer aldığı metot için kullanılır. Tüm test sınıfları çalışmadan önce çalışacak olan metodun başında yer alır. AssemblyCleanup: Assembly tarafından tahsis edilen kaynakların serbest bırakıldığı metot için kullanılır. Tüm test sınıfları çalıştıktan sonra çalışacak olan metodun başında yer alır. TestClass: Test sınıfını oluşturan attribute’tur. Her test metodu için başlangıç durumuna gelir. ClassInitialize: Test sınıfı tarafından tahsis edilen kaynakların yer aldığı metot için kullanılır. ClassCleanup: Test sınıfı tarafından tahsis edilen kaynakların serbest...

Visual Studio Team System 2008 Altında Test Projesi Oluşturmak ve Çalıştırmak (TDD ve Birim Testleri)

Bu makalede Test Driven Development ve Unit Test makalelerinin ardından bir test projesinin nasıl açılacağına ve Unit Test’in Visual Studio Team System 2008 altında nasıl yazılacağına değinilecektir. Test Projesi Oluşturulması File –> New Project altından çıkan penceredeki ağaç yapısında Test Projects/Test Documents seçilir ve Test Project ismi verilerek proje oluşturulur. Şekil 1. Test Projesi Oluşturma Test Sınıfı Oluşturulması Test sekmesinden “New Test” Seçilir. Şekil 2. Test Sınıfı Oluşturma Yeni pencerede Unit Test seçilerek ismi verilir ve test sınıfının oluşması sağlanır.

Birim Testleri

Bir önceki makalemizde TDD yaklaşımına değinmiştik. Bu yazımızda TDD yaklaşımında önemli yer tutan birim testlerini inceleyceğiz. Birim testi bir yazılım projesindeki metotların, fonksiyonların doğru çalışıp çalışmadığını anlamak için oluşturulan testtir. Bir testin birim testi olabilmesi için test edilecek birimlerin ayrı ayrı ele alınması gerekmektedir. Birim testi bir bütünü oluşturan birimlerin entegre testi değildir. Ayrıca bir test; Veritabanı ile ilişkiliyse, Network üzerinden iletişim sağlıyorsa, Dosya sistemiyle ilişkisi varsa, Başka birim testleriyle aynı zamanda çalışamıyorsa, Çalıştırılmak için özel bir konfigürasyon bekliyorsa bu testin birim testi olduğunu söyleyemeyiz (Microsoftun bu konudaki yaklaşımında farklılıkar bulunmaktadır, ilerleyen makalelerde değineceğiz). Bunların yanında 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.

Test-Driven Development(TDD)

Production kodunu yazmadan önce test kodlarını geliştirme yaklaşımıdır. Kısa development döngülerinin tekrarlanması üzerine kurulu bir yazılım geliştirme tekniğidir. 1999 yılında eXtreme Programming ile başlamıştır. İlk önce yazılımcı yeni yazacağı fonksiyon ya da metodun test case’lerini yazar. Bunu yapabilmesi için de o birimin ne yapması gerektiğini iyi bilmesi gerekmektedir, yani analizin düzgün ve istenilen şeylere cevap verebiliyor olması gerekmektedir. İhtiyaçlar Test güdümlü geliştirme production kodu yazılmadan önce yazılmış olan birim testlerinin otomatize bir şekilde yaratılarak çalıştırılmasına ihtiyaç duyar. Testler belli başlı varsayımlar (iddialar)içermelidirler. Test geliştiriciye doğru sonuçları ürettiğini ispatlıyorsa kodun refactor yapılabileceği anlamı çıkarılabilir. Sağlayamıyorsa ya test kodu gözden geçirilmelidir ya da production kodunda düzeltme yapılması gerekebilir. Neden TDD? TDD ile yazılacak kodun test birimleri istenildiği an çalıştırılıp programın daha a...

Build Automation and Continuous Integration

Başta XP (eXtreme Programming) olmak üzere, çevik yazılım geliştirme süreçlerinde ; set otomasyonu ve sürekli tümleştirme (Build Automation and Continuous Integration) işlemleri önemli bir yer tutmaktadır. Bu işlemlerin temel amacı, set yapımı ve kod entegrasyonu maliyetlerini düşürmektir. Ek olarak, ileride yapılacak geliştirmelere bağlı olarak değişim maliyetlerini düşürmek hedeflenmektedir. Büyük ve kapsamlı projelerin set yapım süreçleri de aynı derecede karmaşıktır. Farklı birçok kişi ya da grupların çalışmış olduğu projelerin ve dosyaların bir araya getirilmesi, entegre edilmesi ve uygulamaların test edilmesi yüksek maliyetler oluşturmaktadır. Bu işlemlerin süreklileştirilmesi ve otomatikleştirilmesi, ayrıca yazılım geliştirme süreçlerinin bir parçası haline getirilmesi, önemli kazanımlar getirecektir. İşte tam da bu noktada FinalBuilder gibi çeşitli uygulamalar kullanılmaktadır. FinalBuilder, Vsoft Technologies firmasının geliştirmiş olduğu görsel olarak oluşturulabilen scriptl...

eXtreme Programming – XP

Giriş ve Tarihçe Genelde uç programlama olarak türkçeye çevrilen extreme programming “Değişimlerin Maliyetini Düşürmek” amacıyla geliştirilmiş çevik yazılım süreçlerindendir. Günümüzde özellikle satış odaklı yazılım firmalarında aşağıdaki gibi bir çok sıkıntı yaşanılabilmektedir. Müşteri memnuniyetsizliği Yetişmeyen projeler Haftada 70 saata kadar çalışan yazılımcılar Müşteri isteklerinin ve dolayısıyla Tasarımın sürekli değişmesi Sürekli araya giren işler Planların tutmaması Nihayet %50 oranında başarısız projeler 1996 yılında General Motors şirketininde Smalltalk ile C2 isminde Bordro uygulaması geliştirmekte olan Kent Beck, Ward Cunningham, Ron Jeffries yazılım liderleri yaşadıkları benzer sıkıntılar nedeni ile bu yöntemi geliştirmişler ve 1999 yılında yayınlamışlardır.