Release It’in Hangi Bölümü? Test Harnesses.
Geçtiğimiz günlerde bir “Software Testing alanında mutlaka okunmalı dediğiniz kitapları paylaşabilir misiniz?” postuna ben de efektif bulduğum birkaç kitabı yorum olarak yazmıştım daha sonrasında ise bu kitaplara meraklı çok fazla kişiyle karşılaştım… Açıkçası eski alışkanlıklarına bağlı biri olarak teknik bir bilgi öğrenmek istediğimde elim hemen kitaplara gidiyor ve biliyorum ki kitaplar bana sadece bilgiyi vermekle kalmıyor, vizyonumun genişlemesine de epey yardımcı oluyor.
Tüm bu sebepler birleşince, zaten okuduğum ve insanların merak ettiğini gördüğüm kitapların test odaklı başlıklarını bir seri halinde paylaşmak fikri ortaya çıktı. 3 farklı kitap üzerinden gitmek istediğim bu seride, ilk olarak Michael T. Nygard tarafından yazılmış Release It kitabının Test Harnesses (Test Koşumları) bölümü ile başlamak istedim.
Test Koşumları
Önceki bölümlerde sıkça bahsedildiği gibi; dağıtılmış sistemler, geliştirme veya QA ortamlarında tetiklenmesi zor olan hata modlarına sahiptir. Çeşitli bileşenleri birlikte test etme konusunda daha kapsamlı olmak için genellikle bir “entegrasyon testi” ortamına başvurmamız gerekir ve bu ortamda sistemimiz etkileşimde bulunduğu diğer tüm sistemlerle tam entegre halde bulunmalıdır.
Entegrasyon testinde en büyük güvence için, sistemimizi yayınladığımızda güncel olacak bağımlılıklarımızın sürümlerine karşı test etmek gerekir. Bu yaklaşım tüm şirketi bir seferde yalnızca bir yeni yazılım parçasını test etmeye sınırlar. Ayrıca, günümüz sistemlerinin karşılıklı bağımlılıkları, birbirine kenetlenen bir sistemler ağı yaratır ki, bir entegrasyon test ortamı gerçekten üniter hale gelir -gerçek üretim sistemlerini kopyalayan tek bir küresel entegrasyon testi-. Böyle bir üniter ortam, gerçek üretim ortamları kadar sıkı veya belki de daha fazla değişiklik kontrolüne ihtiyaç duyacaktır.
Daha soyut bir zorluk var. Entegrasyon test ortamları, yalnızca bağımlılıkları doğru çalıştığında sistemin ne yaptığını doğrulayabilir. Uzak sistemi hata döndürmeye kışkırtmak mümkün olsa da, yine de aşağı yukarı spesifikasyonlar dahilinde çalışır. Ancak bu kitabın ana teması, her sistemin eninde sonunda spesifikasyonların dışında çalışmaya başlayacağıdır; bu nedenle, uzak sistem bozuk olduğunda yerel sistemin davranışını test etmek hayati önem taşır. Uzak sistemin tasarımcıları, üretimde doğal olarak meydana gelebilecek tüm kapsam dışı arızaları simüle eden modlarda yerleşik olmadıkça, entegrasyon testinin doğrulamadığı davranışlar olacaktır.
Her entegrasyon noktasının diğer ucundaki uzak sistemi taklit etmek için test kablo demetleri oluşturabilirsiniz. Yazılım mühendisleri test donanımlarını kullandılar, ancak gerektiği kadar kötü niyetli değillerdi. İyi bir test koşum takımı dolambaçlı olmalıdır. Gerçek dünyadaki sistemler kadar kötü ve gaddar olmalıdır. Test koşum takımı, test edilen sistemde iz bırakmalıdır. Görevi, test edilen sistemi alaycı kılmaktır.
Bir test koşum takımı, test amaçlı olduğunu bilir; oynayacak başka bir rolü yoktur. Test donanımı, geliştirmeyi kırmak için her türlü kötü davranışı deneyen küçük bir bilgisayar korsanı gibi davranmalıdır.
Tek bir test kablo demeti birçok uygulamayı bozabilir. Hatta birden fazla geliştiricinin iş istasyonlarından test donanımını kullanmasına izin vererek geliştirme ortamında işlevsel testlere yardımcı olabilir. Test kablonuzun uygulamaları kırmada, hatta öldürmede gerçekten çok iyi olabileceğini unutmayın. Uygulamanızın, onu neyin öldürdüğünü belirtmek için çok fazla bir inilti olmadan ölmesi durumunda, test koşum günlüğü isteklerine sahip olmak kötü bir fikir değildir.
Hataları enjekte eden bir test donanımı, birçok gizli bağımlılığı ortaya çıkaracaktır. İsteklere gecikme eklemek çok daha fazlasını ortaya çıkaracaktır. Tek sınır hayal gücünüzdür.
Neden Mock Obje Değil?
Sahte nesneler, birim testiyle yaygın olarak uygulanan bir tekniktir. Bir mock obje (sahte nesne), test edilen nesne tarafından kullanılmak üzere, birim testinin kendisi tarafından kontrol edilebilen alternatif bir uygulama sağlar.
Bazı sahte nesneler, test edilen nesne kendi yöntemlerini çağırdığında istisnalar oluşturacak şekilde ayarlanabilir. Bu, birim testinin bazı tür hataları, özellikle istisnalarla eşleşenleri simüle etmesine izin verir.
Bir test koşum takımı, sahte nesnelerden farklıdır; çünkü bir sahte nesne, yalnızca herhangi bir arabirime uyan davranış üretmek üzere eğitilebilir. Ağ hatalarına, protokol hatalarına veya uygulama düzeyinde hatalara neden olabilir. Tüm düşük seviyeli hataların doğru istisna türü olarak tanınması, yakalanması ve fırlatılması garanti edilseydi, test kablo demetlerine ihtiyacımız olmazdı.
Sonuç Olarak
- Gerçek uygulamaları çağırmak, yalnızca gerçek uygulamanın kasıtlı olarak üretebileceği hataları test etmenizi sağlar. İyi bir test donanımı, her türlü dağınık, gerçek dünya arıza modunu simüle etmenizi sağlar.
- Test koşum takımı yavaş tepkiler verebilir, hiç tepki vermeyebilir veya gereksiz tepkiler verebilir. Ardından uygulamanızın nasıl tepki verdiğini görebilirsiniz.
- Her entegrasyon noktası için ayrı bir test donanımına ihtiyacınız yoktur. Bir “katil” sunucu, hangi bağlantı noktasına bağlandığınıza bağlı olarak farklı arıza modları oluşturarak birkaç bağlantı noktasını dinleyebilir.
- Test koşum modeli, diğer test yöntemlerini güçlendirir. Birim testleri, kabul testleri, sızma testleri vb. yerine geçmez. Bu tekniklerin her biri, işlevsel davranışı doğrulamaya yardımcı olur. Bir test koşum takımı, uzak sistemlerden izolasyonu korurken “işlevsel olmayan” davranışı doğrulamaya yardımcı olur.
Umarım hoşunuza giden bir yazı olmuştur. Yorumlarınızı bekliyorum. Bu arada yazıyı beğendiyseniz alkış ile beni haberdar edebilirsiniz ve paylaşmamı istediğiniz farklı kitaplar olursa mutlaka yazabilirsiniz.
