UNİT TEST NEDİR? JAVA’DA TEST PİRAMİDİ VE SAĞLAM TEST YAZIMI

Bir bug’ı “canlıda” görmek kadar pahalı çok az şey vardır: kullanıcı etkilenir, itibar zedelenir, ekip paniğe kapılır. Oysa çoğu hatanın kökü, küçük ve izole bir davranışın beklenmedik şekilde bozulmasına dayanır. İşte bu noktada unit test, yazılımın en küçük parçalarının söz verdiği gibi çalıştığını hızlıca kanıtlayan en güçlü güvenlik ağıdır.

Java dünyasında unit test denince akla genellikle JUnit ve Mockito gelir; ama sağlam test yazımı yalnızca framework seçmekten ibaret değildir. Test piramidi, doğru seviyede doğru sayıda test yazmayı; iyi tasarlanmış testler ise refactor sırasında bile bozulmayan, okunabilir ve deterministik kontroller kurmayı hedefler.

Bu yazıda “Unit Test Nedir?” sorusundan başlayıp Java’da test piramidi yaklaşımına, JUnit 5 ile pratik örneklere ve mocking stratejilerine kadar uzanacağız. Amacımız hızlı geri bildirim sağlayan, sürdürülebilir ve ekipçe benimsenebilir bir test kültürü oluşturmak.

Unit test nedir ve neden vazgeçilmezdir?

Temel tanım: birimi izole etmek

Unit test, uygulamadaki en küçük mantıksal birimin (çoğunlukla sınıf/metot) beklenen davranışını doğrulayan otomatik testtir. “Birim”in sınırı ekipten ekibe değişebilir; ancak iyi bir unit test genellikle dış bağımlılıkları (veritabanı, ağ, dosya sistemi) testten ayırır ve sadece ilgili davranışı ölçer. Böylece testler hızlı çalışır ve hata çıktığında nedenini bulmak kolaylaşır.

Hız ve güven: refactor’ı mümkün kılan temel

Unit testlerin en büyük getirisi, değişiklik yaparken güven hissi sağlamasıdır. Kodun içini iyileştirmek (refactor), yeni bir özellik eklemek kadar değerlidir; çünkü bakım maliyetini düşürür. Sağlam unit testler sayesinde, düzenleme sonrası beklenmedik yan etkiler hızla yakalanır. Bu, özellikle uzun ömürlü Java projelerinde kaliteyi korumak için kritik bir alışkanlıktır.

Java’da unit test ekosistemi: JUnit 5 ve pratik araçlar

JUnit 5: modern test yapısı

Java’da unit test yazmanın standart yolu JUnit 5 (Jupiter) ile ilerlemektir. Test sınıflarında senaryoları küçük, tek amaçlı metotlara bölmek; hata mesajlarını anlaşılır kılmak; setup/teardown ihtiyacını minimal tutmak iyi bir başlangıçtır. Testlerin okunabilirliği, testlerin sayısı kadar önemlidir: okuyan kişi testten davranışı net anlamalıdır.

Mockito ve izolasyon: bağımlılıkları yönetmek

Bir servis sınıfı dış sistemlere çağrı yapıyorsa, unit testte bu bağımlılıkları sahtelemek gerekir. Mockito gibi araçlar, bu bağımlılıkların davranışını kontrollü şekilde taklit ederek “sadece bizim sınıfımız ne yapıyor?” sorusuna odaklanmayı sağlar. Buradaki hedef, her şeyi mock’lamak değil; iş değerini taşıyan mantığı izole edebilmektir.

Test piramidi: doğru seviyede doğru miktar

Piramidin katmanları

Test piramidi, testleri katmanlara ayırarak maliyet ve geri bildirim hızını dengeler. En alt katmanda bol ve hızlı unit testler; orta katmanda daha az sayıda entegrasyon testi; en üstte ise sınırlı sayıda uçtan uca (E2E) test bulunur. Java’da bu yaklaşım, hem build sürelerini kontrol altında tutar hem de hata tespitini erken aşamaya çeker.

• Unit test: En hızlı, en izole; mantığı ve kenar durumları yakalar.
• Entegrasyon testi: Bileşenlerin birlikte çalışmasını doğrular; daha yavaştır ama kritik bağlantıları görür.
• E2E/UI test: Kullanıcı akışlarını doğrular; kırılgandır ve bakım maliyeti yüksektir.

Ne kadar test yeterli?

“Yüzde kaç coverage iyidir?” sorusu sık gelir. Coverage bir sinyaldir, hedef değil. Çok yüksek coverage, yanlış noktaları test ediyorsanız güven vermez; düşük coverage ise riskin nerede olduğunu anlamayı zorlaştırır. Daha sağlıklı bir yaklaşım: kritik iş kurallarını, hata geçmişi olan modülleri ve sık değişen alanları önceliklendirmek; test sayısını buna göre artırmaktır.

Sağlam test yazımı: prensipler ve günlük pratikler

Arrange-Act-Assert (AAA) düzeni

Okunabilir testlerin ortak özelliği düzenidir. AAA yaklaşımıyla önce test verisini ve bağımlılıkları hazırlarsınız (Arrange), ardından davranışı tetiklersiniz (Act) ve en sonunda beklentiyi doğrularsınız (Assert). Bu düzen, testin niyetini ilk bakışta anlaşılır hale getirir ve bakım kolaylığı sağlar.

İsimlendirme: davranışı cümle gibi anlatmak

Test ismi, testin dokümantasyonudur. İyi bir test adı; koşulu, eylemi ve beklenen sonucu yansıtır. Örneğin “shouldCalculateDiscount_whenCustomerIsPremium” gibi bir isim, niyeti netleştirir. Bu sayede test raporunda kırmızı bir satır gördüğünüzde, hangi davranışın bozulduğunu anında anlarsınız.

Deterministik test: rastgeleliğe yer yok

Sağlam unit test, her çalıştığında aynı sonucu verir. Zaman, rastgele sayı, sistem saati, sıralama belirsizliği gibi faktörler testleri “flaky” hale getirir. Bu yüzden zaman bağımlı kodlarda saat sağlayıcısı enjekte etmek; koleksiyon sıralamalarını kontrol etmek; çoklu thread senaryolarını unit test yerine daha uygun seviyelerde test etmek tercih edilir.

JUnit 5 ile gerçekçi bir unit test örneği

Basit bir kural: indirim hesaplama

Aşağıda küçük bir indirim hesabı örneği var. Dikkat edin: test, sadece iş kuralını doğruluyor; veritabanı veya HTTP gibi dış bağımlılık yok. Bu, “Java unit test” yaklaşımının en temel formudur: hızlı, net ve tek amaçlı.

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.*;

class DiscountCalculator {
    int calculatePercent(boolean premium, int items) {
        if (items <= 0) return 0;
        if (premium && items >= 3) return 15;
        if (items >= 5) return 10;
        return 0;
    }
}

public class DiscountCalculatorTest {

    @Test
    void shouldReturn15_whenPremiumCustomerAndAtLeastThreeItems() {
        // Arrange
        DiscountCalculator calc = new DiscountCalculator();

        // Act
        int percent = calc.calculatePercent(true, 3);

        // Assert
        assertEquals(15, percent);
    }

    @Test
    void shouldReturn0_whenItemsIsZero() {
        DiscountCalculator calc = new DiscountCalculator();
        assertEquals(0, calc.calculatePercent(true, 0));
    }
}

Bu örnekte iki önemli nokta var: (1) kenar durum (items=0) ayrı bir senaryo olarak ele alındı, (2) testler kısa tutuldu. Böyle testler, değişiklik sırasında hızlı geri bildirim sağlar ve hatayı lokalize eder.

Mocking stratejisi: bağımlılıkları yönetmek ama aşırıya kaçmamak

Mock ne zaman kullanılmalı?

Mocking, özellikle dış servis çağrıları, repository erişimleri veya mesajlaşma altyapısı gibi bileşenlerde işlevseldir. Amaç, unit testte gerçek dış sistemleri çalıştırmak değil, davranışı kontrollü şekilde taklit etmektir. Bu sayede test, sadece bizim sınıfımızın kararlarını ölçer.

Aşırı mock riski ve “etkileşim testi” tuzağı

Her şeyi mock’lamak testleri kırılgan hale getirebilir. Sınıfın iç yapısı değiştiğinde, davranış aynı kalsa bile testler bozulabilir. Bu yüzden etkileşim (verify) odaklı testleri dikkatli kullanmak gerekir. Mümkün olduğunda sonuç (state) doğrulamaya öncelik verin; verify kullanacaksanız kritik sözleşmeleri doğrulayan yerlerde kullanın.

Mockito ile örnek: servis katmanını izole etmek

Repository bağımlılığını sahtelemek

Örnek senaryomuz: Kullanıcı e-posta adresine göre bulunuyor; bulunamazsa hata fırlatılıyor. Unit testte repository’i mock’layıp iki senaryoyu da hızla doğrulayabiliriz. Bu yaklaşım, test piramidinde unit test katmanını güçlü tutar.

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

import java.util.Optional;

import static org.junit.jupiter.api.Assertions.*;
import static org.mockito.Mockito.*;

class User {
    final String email;
    User(String email) { this.email = email; }
}

interface UserRepository {
    Optional<User> findByEmail(String email);
}

class UserService {
    private final UserRepository repo;

    UserService(UserRepository repo) { this.repo = repo; }

    User getRequiredUser(String email) {
        return repo.findByEmail(email)
                .orElseThrow(() -> new IllegalArgumentException("User not found: " + email));
    }
}

@ExtendWith(MockitoExtension.class)
public class UserServiceTest {

    @Mock
    UserRepository repo;

    @InjectMocks
    UserService service;

    @Test
    void shouldReturnUser_whenEmailExists() {
        // Arrange
        when(repo.findByEmail("a@b.com")).thenReturn(Optional.of(new User("a@b.com")));

        // Act
        User user = service.getRequiredUser("a@b.com");

        // Assert
        assertEquals("a@b.com", user.email);
        verify(repo, times(1)).findByEmail("a@b.com");
    }

    @Test
    void shouldThrow_whenEmailMissing() {
        when(repo.findByEmail("x@y.com")).thenReturn(Optional.empty());

        IllegalArgumentException ex =
                assertThrows(IllegalArgumentException.class, () -> service.getRequiredUser("x@y.com"));

        assertTrue(ex.getMessage().contains("x@y.com"));
    }
}

Burada repository sadece bir bağımlılık; asıl değer, service’in karar mantığını doğrulamak. Ayrıca hata mesajını da kontrol ederek, hatanın teşhis edilebilir olmasını garanti altına alıyoruz. Bu, testlerin “sadece geçsin” diye değil, bakım maliyetini düşürmek için yazıldığının iyi bir göstergesidir.

Kenarlara dokunmak: boundary test, parametrik test ve kapsam

Kenar durumları ve iş kuralları

En çok bug üreten yerler genellikle sınır değerlerdir: boş liste, sıfır, negatif değer, maksimum limit, null/empty ayrımı, tarih aralıkları, yuvarlama kuralları. Sağlam test yazımı, “normal akış” kadar bu sınırları da kapsar. Böylece prod ortamındaki beklenmedik girdiler daha erken yakalanır.

Refactor dostu test: iç yapıya değil davranışa odaklanmak

Testler, sınıfın iç implementasyonuna çok bağlanırsa refactor sırasında acıtır. Davranışı doğrulayan testler ise tasarım değişse bile ayakta kalır. Örneğin private metotları test etmeye çalışmak yerine, public davranış üzerinden senaryoları kurmak; test verisini yardımcı metotlarla üretmek; tekrar eden setup’ı minimal tutmak refactor sırasında testlerin değerini artırır.

CI/CD ve test otomasyonu: yerel testten sürekli kaliteye

Pipeline’da testleri konumlandırmak

Unit testler sadece geliştiricinin bilgisayarında çalışınca değerinin bir kısmını kaybeder. En iyi sonuç, her merge/pull request’te testlerin otomatik koşmasıyla alınır. Böylece hatalar ana dala girmeden yakalanır, ekipte “kırık build” kültürü oluşmaz. Test otomasyonu, kaliteyi bir ritüel olmaktan çıkarıp süreç parçası haline getirir.

Flaky test avı: güveni geri kazanmak

Bir test bazen geçip bazen kalıyorsa, ekip bir süre sonra testlere güvenmeyi bırakır. Flaky testleri azaltmak için şunlar işe yarar:

1. Zaman bağımlılıklarını soyutlamak ve sabitlenebilir hale getirmek.
2. Paylaşılan global state’i (statik alanlar, singleton cache) kontrol altına almak.
3. Test sırasına bağımlı senaryoları izole etmek ve veri temizliğini garantilemek.
4. Paralel test çalıştırmada thread-safety sorunlarını ele almak.

İyi haber: Flaky testler çözüldükçe test paketi hızla “güvenilir alarm sistemi”ne dönüşür ve geliştirme hızı artar.

Test kültürünü güçlendirmek: pratik bir yol haritası

Önce kritik akışlar, sonra yayılım

Eğer projede testler azsa, bir anda her şeyi test etmeye çalışmak sürdürülemez. Bunun yerine, hata maliyeti yüksek akışlardan başlayın: ödeme, yetkilendirme, fiyatlandırma, raporlama gibi modüller. Ardından sık değişen kod alanlarını hedefleyin. Bu yaklaşım, kısa sürede ölçülebilir değer üretir.

Ekip standardı: ortak dil ve rehber

Unit testlerin kalitesi, ekip standardı haline gelince yükselir. Kod incelemede testlerin okunabilirliği, isimlendirme, AAA düzeni, mock kullanımının gerekçesi gibi noktaları kontrol listesine eklemek; test yazım rehberi paylaşmak; örnek test şablonları oluşturmak etkili olur. İsterseniz bu yapıyı daha sistematik kurmak için Java Test Otomasyonu Eğitimi içeriğine de göz atabilirsiniz.

Özetle unit test, Java projelerinde hız ve kaliteyi aynı anda büyüten en temel araçtır. Test piramidi ile doğru seviyede test yatırımını yapar, JUnit 5 ve Mockito ile davranışı izole eder, deterministik ve okunabilir testlerle refactor güvenini artırırsınız. Bugün küçük bir modülden başlayıp yarın tüm projeye yayacağınız bu disiplin, uzun vadede en büyük teknik borç azaltma hamlelerinden biridir.