XP projeleri test güdümlü (Test Driven Deevelopment =TDD) ilerler. Programcı, testlerin gerektirdiği sınıfları oluştururken tasarım kararları alır bu bunları uygular. Bu tasarım kararları kodun gelecekte ne oranda yeniliklere açık olduğunu belirler. Seçilen tasarımın test edilebilir yapıda olması da büyük önem taşımaktadır. Aksi taktirde testlerin koddan önce oluşturulması bir sorun haline gelir. TDD tarzı implementasyonda tasarım sorunlarıyla karşılaşmamak ve test edilebilir bir tasarım oluşturmak için takip edilmesi gereken bazı tasarım prensipleri şöyledir:
- Kalıtım (inheritance) yerine kompozisyon kullanılmalıdır.
- Static metot ve Singleton yapılar kullanılmamalıdır.
- Bağımlılıkların isole edilmesi gerekir.
- Bağımlılıkların enjekte (injection) edilmesi, testleri kolaylaştırır.
Bu yazıyı PDF olarak edinebilirsiniz.
Test Edilebilir Tasarım (151,0 KiB, 6.238 yükleme)
Konuyla İlgili Kitaplar
Bu ve diğer yazılarınıda zevkle okudum, gerçekten faydalı işe yarar bilgiler.
her yazılımcının muhakkak bir kere okuması gereken konular.
Bu güzel ve yararlı yazıları yazdığın için tebrik ederim.
Selim
Zaman bulup okudugun ve yorum yaptigin icin ben tesekkür ederim Selim.
Test driven uygulamalarını gayet güzel izah etmişsiniz. Test driven sizi bulmuşken sormak istedim. Test driven uygulamalarını GUI ile iç içe olan yazılımlarda nasıl uygulayabiliriz. Örneğin bir calculator uygulamasında hesap yapacak metodlar TDD ile hazırlanıp GUI ortamına kolay biçimde bağlantıları yapılabilir. Ancak oyun tarzı bir uygulama düşünürsek, örneğin cep telefonlarında bile mevcut olan klasik bir oyun olan Snake(Yılan) oyunu v.s. gibi yazılımlarda nasıl bir süreç işletilmelidir? Örneğin Pro Evolution Soccer gibi oyunların testleri de mutlaka yapılıyordur. Bu tarz grafik arabirimle iç içe uygulamaalar nasıl test ediliyor olabilir?
Merhaba,
bilgisayar oyunu gibi karmasik yapiya sahip uygulamalarda GUI ve ana isletme mantiginin esnek bir bag ile birbirlerine baglanmasina dikkat edilir. Bu aslinda tüm kurumsal mimariler icin gecerli bir durum. Isleme mantigi katmani diger katmanlardan tamamen bagimsiz olacak sekilde tasarlanmalidir. Eger ana isletme mantiginizi veri tabanindan ve arayüzden bagimsiz tutabilirseniz, bu katmani olusturan tüm siniflari test güdümlü gelistirebilirsiniz. Olusturdugunuz mimari sizi hemen bir veri tabani ya da bir gösterme katman catisini kullanmaya zorlamamali. Örnegin hangi veri tabani sistemini kullanacaginizin kararini öteyebilmelisiniz. Bu nasil olabilir? Örnegin müsteri yönetimi uygulamasi hazirliyorsunuz. Uygulamayi test güdümlü gelistirirken, verileri veri tabanina eklemek yerine bir dosyaya yazabilirsiniz. Bu hizli bir sekilde ana isletme katmanini olusturmanizi kolaylastiracaktir. Eger DAO tasarim sablonunu kullandiysaniz, uygulamanin altinda calisan veri tabanini istediginiz sekilde ve zamanda degistirebilirsiniz.
Gösterme katmanida ayni sekilde isletme katmanindan bagimsiz olarak gelistirilebilir. Gösterme katmani test güdümlü gelistirilirken isletme katmaninda var oldugu düsünülen siniflar mocklanir (Mock nesneler olusturulur).
Esnek bir mimarinin ne oldugu hakkinda detayli bilgi edinmek icin Robert C. Martin tarafindan hazirlanan ve http://www.cleancoders.com adresinde yer alan “Clean Code Episode VII – Architecture, Use Cases, and High Level Design” videosuna bakmanizi tavsiye ederim.