Unit Test mi, Integration Test mi? Kapsam, Hız ve Hata Türüne Göre Seçim

Ortak amaç: değişikliği güvenle yapabilmek

Birim testi (unit test) ve entegrasyon testi, kodun beklenen gibi davrandığını otomatik olarak doğrulayan iki test düzeyidir. İkisi de geliştiricinin bir değişiklik yaptıktan sonra mevcut davranışı bozmadığını hızla görmesini sağlar ve sürekli entegrasyon hattında her değişiklikte çalıştırılır. Aradaki fark, testin ne kadar büyük bir parçayı ve hangi gerçek bağımlılıkları kapsadığıdır.

Martin Fowler'ın vurguladığı gibi, iki terim de sektörde tam olarak tek bir tanıma oturmaz. Birim testlerinin ortak özelliği küçük bir parçaya odaklanmaları, geliştiricilerin kendi araçlarıyla yazmaları ve hızlı çalışmalarıdır. Entegrasyon testlerinin özü ise ayrı geliştirilmiş birimlerin birbirine bağlandığında doğru çalışıp çalışmadığını sınamaktır. Ekip içinde bu terimlerin ne anlama geldiğini baştan netleştirmek, test stratejisi tartışmalarındaki yanlış anlamaların önemli bir kısmını önler.

Ölçüt ölçüt temel farklar

• Kapsam: Birim testi / tek bir fonksiyon, sınıf ya da küçük bir modül davranışı. Entegrasyon testi / birden çok birimin ya da kodun veritabanı, mesaj kuyruğu, dış API gibi bir bileşenle birlikte çalışması.
• Bağımlılıklar: Birim testi / dış bağımlılıklar genellikle test dublörleriyle (mock, stub, fake) değiştirilir. Entegrasyon testi / bağımlılıkların gerçeği ya da gerçeğe sadık bir kopyası kullanılır.
• Hız: Birim testi / çok hızlı çalışır; geniş bir birim test paketi geliştirici bilgisayarında kısa sürede koşar. Entegrasyon testi / ağ, disk ve ortam hazırlığı nedeniyle daha yavaştır.
• Yakaladığı hata: Birim testi / mantık hataları, sınır değerler, yanlış hesaplama. Entegrasyon testi / yapılandırma, eşleme (mapping), sorgu, sözleşme ve iletişim hataları.
• Hata yeri: Birim testi / başarısız olduğunda sorunun yeri neredeyse kesindir. Entegrasyon testi / sorunun hangi katmanda olduğunu bulmak için ek inceleme gerekir.
• Bakım: Birim testi / uygulama ayrıntılarına fazla bağlanırsa her yeniden düzenlemede kırılır. Entegrasyon testi / ortam ve test verisi yönetimi bakım yükü getirir.

Örnek: sipariş servisinde iki test düzeyi

Örneğin bir e-ticaret uygulamasında sipariş servisi, sepet tutarına göre indirim hesaplıyor ve siparişi veritabanına kaydediyor. İndirim kuralı için yazılan birim testleri, farklı sepet tutarları, kupon kombinasyonları ve sınır değerler için hesaplama fonksiyonunu tek başına çağırır. Veritabanı ve kupon servisi bu testlerde sahte nesnelerle değiştirilir; testler anında çalışır ve hangi kuralın bozulduğunu tam olarak gösterir.

Aynı servis için yazılan entegrasyon testi ise sipariş deposunun gerçek bir veritabanı örneğine kayıt yapıp yapmadığını, tablo eşlemesinin doğru olup olmadığını ve aynı siparişin iki kez kaydedilmesini engelleyen kısıtın çalıştığını sınar. Testcontainers gibi araçlarla test sırasında geçici bir veritabanı konteyneri açmak, bu testleri geliştirici bilgisayarında ve sürekli entegrasyon hattında tekrarlanabilir hâle getirir. İndirim hesabındaki bir hata birim testinde, yanlış sütun eşlemesi ise yalnız entegrasyon testinde yakalanır.

Dar ve geniş entegrasyon testi ayrımı

Entegrasyon testi çoğu zaman tüm sistemin ayağa kaldırıldığı geniş testlerle karıştırılır. Fowler, bu kavramı ikiye ayırmayı önerir: ayrı geliştirilmiş modüllerin birlikte doğru çalıştığını sınayan dar kapsamlı testler ve birden çok modülden oluşan bir sistemin bütün olarak beklenen gibi çalıştığını sınayan geniş testler.

Dar entegrasyon testi, örneğin yalnız sipariş servisinin katalog servisiyle konuşan kodunu çalıştırır ve katalog servisinin sadık bir test dublörüne karşı koşar. Dublörün gerçek servisle uyumlu olduğu ise ayrı sözleşme testleriyle (contract test) doğrulanır. Bu kurgu, gerçek dış servisleri test sırasında hiç çalıştırmadan entegrasyona güven duymayı sağlar ve yapı (build) sürecini hızlandırır. Tüm gerçek servislerin birlikte çalıştığı uçtan uca testler ise az sayıda kritik yolla sınırlı bir son kontrol olarak kalır.

Hangi durumda hangisine ağırlık verilir?

Birim testine ağırlık verin: • İş kuralları, hesaplamalar ve karar mantığı yoğunsa. • Kod sık yeniden düzenleniyorsa ve hızlı geri bildirim gerekiyorsa. • TDD ile çalışılıyorsa; testi önce yazmak doğal olarak birim düzeyinde başlar.

Entegrasyon testine ağırlık verin: • Kodun büyük kısmı veri okuma, yazma ve dönüştürme gibi bileşenler arası işlerden oluşuyorsa. • ORM eşlemeleri, veritabanı sorguları, mesajlaşma ve harici API çağrıları kritikse. • Mikroservisler arasında sözleşme uyumsuzlukları sık sorun çıkarıyorsa.

Test piramidi yaklaşımı, tabanda çok sayıda hızlı birim testi, ortada daha az entegrasyon testi ve tepede az sayıda uçtan uca test önerir. Ancak bu oran her mimariye aynen uymaz; mantığı az, entegrasyonu yoğun servislerde entegrasyon testlerinin ağırlığı artabilir. Önemli olan, her hata türünün onu en ucuza yakalayan düzeyde test edilmesidir.

Sık yapılan hatalar

• Her bağımlılığı taklit edip (mock) davranış yerine uygulama ayrıntısını test etmek; kod yeniden düzenlendiğinde testler gerçek bir hata olmadan kırılır.
• Veritabanına bağlanan testleri birim testi diye adlandırmak; yavaş testler hızlı paketin içine karışır ve geliştiriciler testi çalıştırmayı bırakır.
• Entegrasyon testlerinde paylaşılan, kirli bir test veritabanı kullanmak; testler sıraya bağımlı hâle gelir ve aralıklı başarısız olur.
• Yalnız kapsama (coverage) oranına bakmak; yüksek oran, bileşenler arası hataların yakalandığını göstermez.
• Entegrasyon sorunlarını yalnız uçtan uca testlerle yakalamaya çalışmak; bu testler yavaş, kırılgan ve hata yerini göstermekte zayıftır.

Mindset programlarında birim ve entegrasyon testi

Test Driven Development (TDD) ve Unit Testing Uzmanlığı Eğitimi; unit testing temelleri, mocking ve test izolasyonu teknikleri, test kapsamı ve kod kalitesi analizi ile TDD ile güvenli yeniden düzenleme başlıklarını işler. Yazılım Mimarisi ATDD ve Test Stratejisi eğitimi ise birim test stratejisi, entegrasyon ve servis test stratejisi, uçtan uca test ve test ortamları ile CI/CD hattında test entegrasyonunu kurumsal bir test stratejisi içinde ele alır.

JavaScript ekipleri için Jest ile JavaScript Birim Testleri eğitimi, taklit stratejileri ve asenkron kodun test edilmesi modülleriyle birim düzeyine odaklanır.