Yazılımda testlerin gerekliliğini ve hangi testlerin ne zaman uygulandığını açıklamak amacıyla şemsiye modeli ismini verdiğim bir model oluşturdum. Bu yazımda sizlerle bu modeli ve işlevini paylaşmak istiyorum.

Şemsiyeler gerçek hayatta yağmurdan ve yer yer güneşten korunmak için kullanılır. Yazılım süreçleri için oluşturduğum şemsiye modelinde yazılım testleri uygulamayı korumak için açılan şemsiyeleri temsil etmektedir. Şemsiyenin büyüklüğüne ve işlevine göre uygulamayı hatalara karşı korumak ve sağlıklı bir şekilde gelişmesini sağlamak mümkündür.

Şemsiye modelinde değişik büyüklükte şemsiyeler yer almaktadır. Açılan bir şemsiyenin kapsadığı bir alan mevcuttur. Bu alan şemsiyenin koruyabildiği alandır. Değişik test türleri değişik büyüklükte alanları koruyabilirler. Testleri olmayan bir uygulamayı şemsiye modeli ayazda ve yağmurda kalmış olarak tanımlar. Böyle bir uygulamanın akıbeti bellidir.

Ayazda kalmış bir uygulamaya göz atarak başlayalım. Resim 1 de böyle bir uygulama görülmekte.

Resim 1

Resim 1 de yer alan uygulamanın yağmurdan korunması yani hatasız olması ve kalabilmesi için hiçbir şemsiye açılmamış yani test oluşturulmamıştır. Böyle bir uygulamanın geliştirilmesi tamamen rus ruleti benzeri bir girişimdir. Testler olmadığı sürece yani bir veya daha fazla koruyucu şemsiye açılmadığı sürece bu uygulama su altında kalmak zorundadır. Projenin belli bir aşamasından sonra ekibin tek işi, su dolan teknenin batmasını engellemeye çalışmak olacaktır. Teknenin su dolmasını engelleyici bir mekanızma olmadığından, su tahliyesi bir şey ifade etmemektedir. Tekne er ya da geç batacaktır.

Şimdi her türlü hava koşulunda uygulamayı istenilen hedefe taşımak için atılması gereken adımlardan bahsetmek istiyorum. Şemsiye modelinde değişik büyüklüklerde, uygulamanın belli bir kısmını ya da tümünü yağmurdan koruyacak türde şemsiyeler yani test türleri yer alıyor. Küçük şemsiyelerin kullanımı ve taşınmaları yani test türü olarak oluşturulmaları ve koşturulmaları kolay. Bu tür testler için gerekli yatırım düşük. Buna karşın kapsama alanları kısıtlı yani küçük şemsiyelerle uygulamanın tümümü korumak mümkün değil. Bu küçük şemsiyeleri bir araya getirip, uygulamanın her tarafını koruma altına almak da mümmkün değil, çünkü yapıları itibari ile bir araya getirilip, daha büyük bir şemsiye oluşturma kabiliyetine sahip değiller. Buna karşın şemsiye modelinde tüm uygulamayı ya da büyük bölümlerini koruma altına alabilecek daha büyük şemsiyeler de bulunmakta. Bu tür şemsiyeler çok büyük bir alanı koruyabiliyorlar. Lakin oluşturulmaları ve koşturulmaları zaman alıcı. Bu yüzden maliyetleri yüksek. Şemsiye modeli ile değişik büyüklükte şemsiyeler kombine edilerek, uygulanın tümünü koruma altına almak mümkün. Şimdi bu şemsiyeleri, nasıl kullanıldıklarını, oluşturulma maliyetlerini ve uygulamayı nasıl koruklarını yakından inceleyelim.

Şemsiye modelindeki en küçük şemsiyeler birim testleridir. Birim testleri sadece bir kod birimi, bu bir metot, sınıf ya da modül olabilir, test etmek için kullanılırlar. Kod birimlerinin dışa bağımlılıkları mevcut olabilir. Birim testlerinde bu bağımlılıklar yok sayılır ve mock olarak isimlendirilen ve bağımlılıkları simüle eden kod birimleri ile yer değiştirilmeleri sağlanır. Bu şekilde sadece test edilen kod birimi bünyesinde olup, bitenleri test etmek mümkündür. Nihayi amaç kod biriminin bağımlılıkları olmadan nasıl davranış gösterdiğinin test edebilmesidir. Eğer teste test edilen kod biriminin bağımlılıkları da dahil olursa, test birim testi olmaktan çıkar ve bir entegrasyon testine dönüşür. Bu tür testlerin kullanımı da şemsiye modelinde yer almaktadır. Lakin birim testleri ile sadece işletme mantığı barındıran kod birimlerine konsantre olunur ve birim şemsiyesi açılarak belli bir kod birimi koruma altına alınır ve bağımlılıkları göz ardı edilir. Bu bağımlılıkların dolaylı olarak test edilmediği anlamına gelmektedir.

Resim 2

Resim 2 de birim şemsiyesinin işlevi görülmektedir. Bu örnekte D ismini taşıyan modül birim testleri ile koruma altına alınmıştır ve yağmur görmesi engellenmektedir. D ve diğer modüller arasında interaksiyon olduğunu düşünecek olursak, birim testleri ile bu interaksiyonu test etmediğimiz için D için açmış olduğumuz şemsiye sadece D bünyesindeki işleteme mantığını korur türdendir. Eğer interaksiyon içindeki modülleri tamamen koruma altına alacak büyüklükte bir şemsiyemiz yani testimiz yoksa, bu durumda uygulama entegrasyonun gerçekleştiği noktalarda yine yağmura mağruz kalacaktır, çünkü bu alanlar birim testleri ile test edilemez. Böyle bir şemsiyeyi bir entegrasyon testi yazarak, oluşturabiliriz. Resim 3 de bu yapıyı görmekteyiz.

Resim 3

Entegrasyon testlerinde birbirlerine bağımlı olan modüllerin davranışları test edilir. Örneğin müşteri bilgilerini edinmek için kullanılan CustomerDao ismindeki bir sınıfı test etmek için veri tabanına ihtiyaç duyulmaktadır. Birim testinde veri tabanı erişimi mock olarak implemente edilirken, entegrasyon testinde CustomerDao sınıfının erişebileceği bir veri tabanı oluşturulur ve bu iki modülün entegrasyonu test edilir.

Birim testleri ile CustomerDao sınıfının entegre edilmiş bir sistemindeki işlevini test etmek mümkün değildir. Bu belirsizlik şemsiyenin büyüklüğünü ve kapsama alanını tayin etmektedir. Bu sebepten dolayı birim testleri ile tüm uygulamayı koruma altına almak mümkün değildir, çünkü birim testleri “gerçek olmayan bir ortamda” kabiliyetleri çerçevesinde izole edilmiş kod birimleriyle ilgilidirler. Gerçek bir ortamda bir veya daha fazla modülün birlikteliğini test etmek için entegrasyon testlerine ihtiyaç duyulmaktadır. Entegrasyon testleri gerçeğe yakın bir ortam oluşturubildiklerinden, kapsama alanları daha geniştir ve böylece uygulamanın daha geniş alanlarına hitap edebilirler.

Resim 3 de entegrasyon şemsiyelerinin birim şemsiyelerine nazaran daha büyük ve ağır oldukları görülmektedir. Bu sebepten dolayı taşınmaları daha zordur. Bu entegrasyon testlerinin birim testlerine nazaran daha maliyetli oldukları ve koşturulmalarının daha zaman alıcı olduğu anlamına gelmektedir.

Birim testlerinde de olduğu gibi sadece entegrasyon testleri ile tüm uygulamayı koruma altına almak mümkün değildir, çünkü entegrasyon testleri tüm sistem entegrasyonu yerine bazı modüllerin entegrasyonuna ağırlık vermektedirler. Tüm sistem entegre edilip, test edilmediği sürece, açılan şemsiyelerin altında yer alamayan kod birimleri mutlaka olacaktır ve daha büyük şemsiyeler açılmadığı sürece, bu kod birimleri ayazda kalacaktır. Bu sistem hatalarının var olacakları anlamına gelmektedir.

Tüm uygulamayı kapsama alanına alabilecek kabiliyete sahip testler onay/kabul testleridir. Resim 4 de onay/kabul şemsiyesinin işlevi görülmektedir.

Resim 4

Onay/kabul testleri uygulamayı bir kara kutu olarak görürler ve onun kullanıcı perspektifinden test edilmesini mümkün kılarlar. Onay/kabul testleri kullanıcı ya da müşteri tarafından tanımlanan onay/kabul kriterlerini (acceptance criteria) baz alırlar ve programcılar tarafından implemente edilirler. Onay/kabul testleri ile bir uygulayı gerçek koşullarda en tepesinden en alt katmanına kadar entegre test etmek mümkündür. Topdown olarak isimlendirilen bu yaklaşım uygulamada kullanıcıların ihtiyaç duyduğu tüm uygulama davranışlarının test edilmesini mümkün kılmaktadır. Çalışır durumda olan onay/kabul testleri uygulamanın beklenen davranışı sergilediğinin kanıtıdır ve bu sebepten dolayı müşteri ya da kullanıcı tarafından uygulamanın onaylanmasını / kabul görmesini beraberinde getirir.

Bir uygulamanın çalışır durumda olduğunun en iyi ispatı onay/kabul testlerinin varlığı ve çalışır durumda olmalarıdır. Onay/kabul testleri ile uygulamanın sahip olması gereken tüm davranış biçimleri test edilebilir. Lakin resim 4 de de görüldüğü gibi onay/kabul şemsiyenin büyüklüğü maliyetine işaret etmektedir. Bu tür testlerin implementasyonları karmaşık yapılarından dolayı zaman alıcı olabilir. Bu proje maliyetini artırıcı bir durumdur. Bunun yanı sıra onay/kabul testleri tüm sistem entegrasyonunu hedef aldıklarından, koşturulma zamanları buna orantılı olarak uzundur.

Sadece onay/kabul testlerinin uygulanması bize tüm uygulamayı kapsayacak bir koruyucu şemsiyenin açılabileceği izlenimini vermekle birlikte, şemsiyenin büyüklüğünden doğan hantallık, projenin çevikliğini aksatacaktır. Buradaki yazımda da değindiğim gibi çeviklik yazılım testleri ile bir uygulamanın istenilen şekilde yoğrulması için gerekli ortamın oluşturulmasıdır. Uygulamayı yeni müşteri gereksinimleri doğrultusunda yeniden yapılandırabilmek için yapılan değişikliklerin sebep olduğu yan etkilerin lokalizasyonu için geribildirime ihtiyaç duyulmaktadır. Bu geribildirim ne kadar hızlı alınırsa, yeniden yapılandırma o oranda ivme kazanacaktır. Onay/kabul testleri bu tür geribildirim sağlama yetisine sahiplerken, koşturulma zamanları uzun olduğundan dolayı, hızlı bir şekilde geribildirim alıp, gerekli yeniden yapılandırma işlenimi seri halde gerçekleştirmek mümkün değildir. Bunun için daha hızlı geribildirim sağlayan bir mekanizmaya ihtiyac duyulmaktadır. Bu mekanizmanın ismi birim testleridir.

Görüldüğü gibi tüm sistemi koruma altına almak ve bunun yanı sıra çeviklikten ödün vermemek için değişik türdeki testlerin kombine edilmesi gerekmektedir. Bir sonraki yazımda şemsiye modelinin nasıl implemente edilebileceğini bir örnek üzerinde sizlerle paylaşacağım.

EOF (End Of Fun)
Özcan Acar