Ana içeriğe atla

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.

Projedeki Hangi Kısımlar için Birim Testi Yazılmalıdır?
Bir nesne yazıldığında o nesnenin tüm özelliklerini barındıran test sınıfını da yazmak gerekmektedir ki bu nesne parametreler alan ve uygun değerler döndüren public metotları içermektedir. Yine de birim testinin projedeki hangi kısımlar için yazılacağı yazılım geliştiriciye bağlıdır. Ancak nesne tabanlı programlamada genel yaklaşım bir sınıf içerisindeki tüm public metotlar için birim testi yazmak yönündedir. Değişkenlere ulaşım amaçlı kullanılan getter ve setter’lar için veya hatanın çok kolay bulunabileceği, işlevinin bir bakışta anlaşılabileceği metotlar için birim testi yazılmaması öngörülebilir. Ancak tüm metotlar için birim testinin yazılmaması bir projede test edilen kodların tüm kodlara oranı (Code Coverage) yüzdesini düşürmesi açısından dezavantaj olarak görülebilir.
Birim Testinin Yazılım Geliştirme Sürecine Katkıları
  • Sonradan ortaya çıkabilecek hataların oluşturacağı maliyeti en aza indirger.
  • Refactoring sonucundaki test maliyetini düşürür: Yeniden ele alınan kod bloklarında bozulma olup olmadığını anlamak amacıyla ilgili kod bloğu için önceden oluşturulmuş birim testi çalıştırılarak sonucun doğruluğu kolayca kontrol edilebilir.
  • Code Inspection (kod inceleme) açısından çok verimlidir.
  • Uzun vadede birim testi olmadan kod yazmaktan daha hızlı ve verimli kod yazmayı sağlar çünkü sonrasında oluşacak hatalara dönüp bakma ihtimalini en aza indirger.
  • Yazılan kodun en dip seviyede anlaşılmasını sağlar çünkü çok net anlaşılmayan kodun birim testini yazmak imkansızdır. Bu da çok daha temiz ve hatasız kod bloklarının ortaya çıkmasını sağlar.
  • Bir kod bloğunun işlevi birim testine bakılarak çok daha kolay anlaşılabilir, bu da dokümantasyon niteliğinde olabilir.
Çok Fazla Fonksiyonel Test Olması Durumundaki Sıkıntı
Fonksiyonel testler çok önemlidir. Bu testlerde bir fonksiyonda yaşanan sıkıntı birbirine bağlı tüm fonksiyonları etkilemektedir. Düzeltilen hata da o fonksiyona bağlı tüm fonksiyonlarda düzeldiği anlamına gelebilir.
Ancak birim testinde durum böyle değildir. Hatanın ilgili fonksiyonu başka fonksiyonlarla bağlantılı olmadığı için alınan hata da diğer fonksiyonları etkilememektedir. Bu da birim testin amacını karşılamaktadır.
Grafiksel olarak; Birbirine bağlı fonksiyonların birinde çıkan hata diğerlerini de etkilemektedir ve çözüm hepsinde çözümdür.
image
Birim testinde ise fonksiyonlar birbirlerine bağlı olmadıklarından hata sadece kendi fonksiyonunu etkilemektedir ve çözümü yine sadece kendisini bağlamaktadır.
image
Mock (Taklit) Obje
Karmaşık objeleri basitleştirilmiş fonksiyonlarıyla taklit eden objeye Mock objesi denir. Bir birim testi donanım, bağlantı veya başka herhangi bir kaynağı benzetimi açısından Mock objelere ihtiyaç duymaktadır. Çünkü bahsi geçen bu dış kaynak fonksiyonları birim testi kümesinde yer almamaktadırlar. Birim testi aynı zamanda performans için de Mock objelere ihtiyaç duymaktadır. Çünkü canlı sistemde çalışan bir obje çok yüklü olabilir ve bu nesnenin sadece belirli kısımlarına ihtiyaç duyulabilir. Unutulmamalıdır ki test performansı çok önemlidir. Aksi takdirde test çalıştırılması külfete dönüşebilir.
Entegre Testi (Entegrasyon Testi)
Yazılım modüllerinin birleştirilerek grup halinde test edilmesine Entegre Tesi (Integration Test) denmektedir. Birim testinin üstünde sistem testinin altında yer almaktadır. Birim testleri gibi sadece bir birimi kapsamaz ancak sistem testleri gibi de tüm sistemin testi için kullanılmaz. Entegre Testi sadece ilişkili modüllerin bir arada test edilmesine olanak kılar.
Ömer KİREMİTÇİ, Armağan DÖKER

Yorumlar

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Ama

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde ( 1 , 2 ) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki: “Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler , Sistem (Proje kapsamını belirtir) , Use Caseler ve bunlar ara