Birim Testlerinde Bağımlılık Yönetimi ve Mocking İhtiyacı

Yazılım geliştirmede, birim testleri (unit tests) kodumuzun güvenilirliğini ve kalitesini sağlamanın temel taşlarından biridir. Ancak, test edilen sınıfın (System Under Test – SUT) dış bağımlılıkları olduğunda, bu bağımlılıkları yönetmek test yazmayı karmaşık hale getirebilir. İşte bu noktada Mockito gibi mocking kütüphaneleri ve özellikle @InjectMocks anotasyonu devreye girer.

Bu rehberde, Mockito’nun @InjectMocks anotasyonunun ne olduğunu, nasıl çalıştığını ve birim testlerinizde bağımlılık enjeksiyonunu nasıl basitleştirdiğini ayrıntılı olarak inceleyeceğiz. Amacımız, testlerinizi daha okunabilir, sürdürülebilir ve etkili hale getirmenize yardımcı olacak pratik bilgiler sunmaktır.

Birim Testlerinde Bağımlılık Yönetimi ve Mocking İhtiyacı

Bir yazılım bileşenini izole bir şekilde test etmek istediğimizde, bu bileşenin bağlı olduğu diğer bileşenlerin (örneğin, bir veritabanı servisi, harici bir API istemcisi, başka bir iş mantığı sınıfı) gerçek implementasyonlarını kullanmak genellikle istenmez. Bunun birkaç nedeni vardır:

• İzolasyon Eksikliği: Gerçek bağımlılıklar kullanıldığında, test edilen bileşenin kendisinden kaynaklanmayan hatalar test sonuçlarını etkileyebilir. Bu, hatanın gerçek kaynağını bulmayı zorlaştırır.
• Performans: Veritabanı işlemleri veya ağ istekleri gibi gerçek bağımlılıklar, testlerin yavaş çalışmasına neden olur. Birim testlerinin hızlı olması esastır.
• Deterministik Olmama: Gerçek bağımlılıklar, her zaman aynı sonucu vermeyebilir (örneğin, veritabanındaki veriler değişebilir, ağ hataları oluşabilir). Birim testleri deterministik olmalı, yani her zaman aynı girdi için aynı çıktıyı üretmelidir.
• Senaryo Kısıtlamaları: Belirli hata durumlarını veya uç durumları (edge cases) gerçek bağımlılıklarla simüle etmek zor veya imkansız olabilir.

Bu sorunları çözmek için “mocking” (taklit etme) veya “stubbing” (taklit veri sağlama) tekniklerini kullanırız. Mockito, bu teknikleri Java’da kolayca uygulamanızı sağlayan popüler bir kütüphanedir. Bağımlılıkları taklit ederek, test ettiğimiz sınıfın dış dünya ile etkileşimlerini kontrol edebilir ve belirli davranışları simüle edebiliriz.

@Mock ve @InjectMocks Anotasyonlarını Tanıyalım

Mockito, test yazmayı kolaylaştıran çeşitli anotasyonlar sunar. Bu anotasyonlardan ikisi, bağımlılık enjeksiyonu bağlamında birlikte kullanıldığında güçlü bir ikili oluşturur: @Mock ve @InjectMocks.

@Mock Anotasyonu

@Mock anotasyonu, bir sınıfın taklit (mock) edilmiş bir örneğini oluşturmak için kullanılır. Bu taklit nesneler, gerçek implementasyonları yerine, test senaryomuzda tanımladığımız davranışları sergiler. Örneğin, bir veritabanı deposu (repository) sınıfının taklit edilmiş bir versiyonunu oluşturarak, veritabanı çağrıları yerine belirli verileri döndürmesini sağlayabiliriz.

import org.mockito.Mock;

public class UserServiceTest {

    @Mock
    private UserRepository userRepository; // UserRepository'nin taklit edilmiş bir örneği

    // ... diğer test kodları
}

@InjectMocks Anotasyonu

@InjectMocks anotasyonu ise test ettiğimiz sınıfın (System Under Test – SUT) bir örneğini oluşturur ve bu örneğin bağımlılıklarını, test sınıfında tanımlanmış @Mock veya @Spy anotasyonlu alanlardan otomatik olarak enjekte etmeye çalışır. Bu, manuel olarak bağımlılıkları oluşturup SUT’a geçirme zahmetini ortadan kaldırır ve test kodunu daha temiz hale getirir.

import org.mockito.InjectMocks;
import org.mockito.Mock;

public class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService; // Test edilen UserService örneği

    // ... diğer test kodları
}

Mockito, @InjectMocks ile işaretlenmiş bir nesneye bağımlılıkları enjekte ederken belirli bir sıra izler:

1. Constructor Enjeksiyonu: Öncelikle, enjekte edilecek tüm mock’ları parametre olarak alabilen bir constructor arar. Eğer birden fazla uygun constructor varsa, en çok bağımlılığı enjekte edebilen constructor’ı tercih eder.
2. Setter Enjeksiyonu: Eğer uygun bir constructor bulamazsa, bağımlılıkları enjekte etmek için setter metotlarını (örneğin, setUserRepository(UserRepository repository)) kullanmaya çalışır.
3. Field Enjeksiyonu: Son çare olarak, bağımlılıkları doğrudan alanlar (fields) üzerinden enjekte etmeye çalışır.

Bu otomatik enjeksiyon mekanizması, test kurulumunu büyük ölçüde basitleştirir ve bağımlılık enjeksiyonu prensiplerine uygun kod yazmayı teşvik eder.

@InjectMocks ve @Mock Birlikte Kullanımı: Pratik Örnekler

Şimdi, @InjectMocks ve @Mock anotasyonlarını bir örnek üzerinden nasıl kullanacağımıza bakalım. Bir UserService sınıfımız olduğunu ve bu sınıfın kullanıcı verilerini yönetmek için bir UserRepository bağımlılığına sahip olduğunu varsayalım.

Örnek Sınıflar (System Under Test ve Bağımlılığı)

// UserRepository.java
public class UserRepository {
    public User findUserById(String id) {
        // Gerçekte veritabanı sorgusu yapar
        System.out.println("Veritabanından kullanıcı aranıyor...");
        throw new UnsupportedOperationException("Gerçek veritabanı erişimi testlerde kullanılmamalıdır!");
    }

    public void saveUser(User user) {
        // Gerçekte veritabanına kaydeder
        System.out.println("Kullanıcı veritabanına kaydediliyor...");
        throw new UnsupportedOperationException("Gerçek veritabanı erişimi testlerde kullanılmamalıdır!");
    }
}

// User.java (Basit bir POJO)
public class User {
    private String id;
    private String name;
    private String email;

    public User(String id, String name, String email) {
        this.id = id;
        this.name = name;
        this.email = email;
    }

    // Getter ve Setter'lar
    public String getId() { return id; }
    public void setId(String id) { this.id = id; }
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public String getEmail() { return email; }
    public void setEmail(String email) { this.email = email; }

    @Override
    public String toString() {
        return "User{id='" + id + "', name='" + name + "', email='" + email + "'}";
    }
}

// UserService.java (Test Edilecek Sınıf - SUT)
public class UserService {
    private final UserRepository userRepository;

    // Constructor Enjeksiyonu
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public User getUserDetails(String userId) {
        if (userId == null || userId.isEmpty()) {
            throw new IllegalArgumentException("Kullanıcı ID boş olamaz.");
        }
        return userRepository.findUserById(userId);
    }

    public boolean createUser(String id, String name, String email) {
        if (id == null || name == null || email == null) {
            throw new IllegalArgumentException("Kullanıcı bilgileri eksik olamaz.");
        }
        User newUser = new User(id, name, email);
        userRepository.saveUser(newUser);
        return true;
    }
}

UserService İçin Birim Testi

Şimdi UserService sınıfını test edelim. UserRepository‘nin gerçek implementasyonu yerine Mockito ile oluşturduğumuz bir mock’u kullanacağız.

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;

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

public class UserServiceTest {

    @Mock // UserRepository'nin taklit edilmiş bir örneğini oluşturur
    private UserRepository userRepository;

    @InjectMocks // userService örneğini oluşturur ve userRepository mock'unu enjekte eder
    private UserService userService;

    @BeforeEach
    void setUp() {
        // Mockito anotasyonlarını başlatır. Bu, @Mock ve @InjectMocks alanlarının işlenmesini sağlar.
        // JUnit 5 ile MockitoExtension kullanılıyorsa bu satıra gerek kalmaz.
        MockitoAnnotations.openMocks(this); 
    }

    @Test
    void testGetUserDetails_Success() {
        // GIVEN: Belirli bir kullanıcı ID'si için UserRepository'nin ne döndüreceğini tanımla
        String userId = "123";
        User mockUser = new User(userId, "Ahmet Yılmaz", "ahmet@example.com");
        when(userRepository.findUserById(userId)).thenReturn(mockUser);

        // WHEN: UserService'in getUserDetails metodunu çağır
        User resultUser = userService.getUserDetails(userId);

        // THEN: Sonucun beklenen kullanıcı ile eşleştiğini doğrula
        assertNotNull(resultUser);
        assertEquals(userId, resultUser.getId());
        assertEquals("Ahmet Yılmaz", resultUser.getName());
        assertEquals("ahmet@example.com", resultUser.getEmail());

        // UserRepository'nin findUserById metodunun doğru parametrelerle çağrıldığını doğrula
        verify(userRepository, times(1)).findUserById(userId);
        // Başka hiçbir metodun çağrılmadığını doğrula (isteğe bağlı)
        verifyNoMoreInteractions(userRepository); 
    }

    @Test
    void testGetUserDetails_UserNotFound() {
        // GIVEN: UserRepository'nin null döndüreceğini tanımla (kullanıcı bulunamadı)
        String userId = "456";
        when(userRepository.findUserById(userId)).thenReturn(null);

        // WHEN: UserService'in getUserDetails metodunu çağır
        User resultUser = userService.getUserDetails(userId);

        // THEN: Sonucun null olduğunu doğrula
        assertNull(resultUser);
        verify(userRepository, times(1)).findUserById(userId);
    }

    @Test
    void testGetUserDetails_InvalidUserId() {
        // WHEN & THEN: Geçersiz ID ile çağrıldığında IllegalArgumentException fırlatıldığını doğrula
        assertThrows(IllegalArgumentException.class, () -> {
            userService.getUserDetails("");
        });
        // UserRepository'nin hiçbir metodunun çağrılmadığını doğrula
        verifyNoInteractions(userRepository);
    }

    @Test
    void testCreateUser_Success() {
        // GIVEN: UserRepository'nin saveUser metodunun hiçbir şey yapmayacağını tanımla (void metodlar için varsayılan davranış)
        // doNothing().when(userRepository).saveUser(any(User.class)); // Bu satır isteğe bağlıdır, varsayılan olarak void metodlar bir şey yapmaz.

        // WHEN: UserService'in createUser metodunu çağır
        boolean success = userService.createUser("789", "Ayşe Can", "ayse@example.com");

        // THEN: İşlemin başarılı olduğunu doğrula
        assertTrue(success);

        // UserRepository'nin saveUser metodunun doğru parametrelerle çağrıldığını doğrula
        // any(User.class) ile herhangi bir User nesnesinin kabul edildiğini belirtiriz.
        verify(userRepository, times(1)).saveUser(any(User.class));
    }

    @Test
    void testCreateUser_InvalidInput() {
        // WHEN & THEN: Eksik bilgi ile çağrıldığında IllegalArgumentException fırlatıldığını doğrula
        assertThrows(IllegalArgumentException.class, () -> {
            userService.createUser("101", null, "test@example.com");
        });
        // UserRepository'nin hiçbir metodunun çağrılmadığını doğrula
        verifyNoInteractions(userRepository);
    }
}

Yukarıdaki örnekte:

• @Mock private UserRepository userRepository; satırı, UserRepository sınıfının sahte bir örneğini oluşturur. Bu örnek, gerçek veritabanı işlemlerini yapmaz.
• @InjectMocks private UserService userService; satırı, UserService sınıfının bir örneğini oluşturur ve bu örneğe userRepository mock’unu constructor aracılığıyla otomatik olarak enjekte eder.
• @BeforeEach void setUp() { MockitoAnnotations.openMocks(this); } metodu, her test metodu çalışmadan önce Mockito anotasyonlarını başlatır. JUnit 5 kullanıyorsanız, @ExtendWith(MockitoExtension.class) anotasyonunu test sınıfına ekleyerek bu satırı atlayabilirsiniz.
• when(userRepository.findUserById(userId)).thenReturn(mockUser); gibi satırlarla, mock objesinin belirli bir metot çağrısına nasıl yanıt vereceğini (yani ne döndüreceğini) belirtiriz.
• verify(userRepository, times(1)).findUserById(userId); gibi satırlarla, mock objesinin belirli bir metodunun beklendiği gibi çağrılıp çağrılmadığını doğrularız.

Bu yapı sayesinde, UserService sınıfının iç mantığını, UserRepository‘nin karmaşık veya yavaş gerçek implementasyonundan etkilenmeden, izole bir şekilde test edebiliriz.

İleri Seviye Kullanım ve Pratik İpuçları

JUnit 5 ve MockitoExtension

JUnit 5 kullanıyorsanız, @ExtendWith(MockitoExtension.class) anotasyonunu test sınıfınıza ekleyerek MockitoAnnotations.openMocks(this); çağrısını otomatik hale getirebilirsiniz. Bu, test kurulumunu daha da basitleştirir.

import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class) // Bu satır Mockito anotasyonlarını otomatik başlatır
public class UserServiceTest {
    // ... test kodları
}

Birden Fazla Constructor Durumu

Eğer test edilen sınıfın birden fazla constructor’ı varsa, Mockito @InjectMocks ile enjekte edilecek mock’ları en iyi eşleşen constructor’a göre bulmaya çalışır. Genellikle, en fazla parametreyi alabilen ve tüm parametreleri için uygun mock’lar bulunan constructor’ı tercih eder. Eğer açıkça belirtilmezse ve birden fazla eşleşen constructor varsa, Mockito’nun davranışı belirsiz olabilir veya beklediğiniz gibi çalışmayabilir. Bu yüzden, genellikle tek bir ana constructor’a sahip olmak veya constructor’ların bağımlılıklarını açıkça belirten bir hiyerarşi izlemek iyi bir pratik olarak kabul edilir.

Enjekte Edilemeyen Bağımlılıklar

Eğer @InjectMocks ile işaretlenmiş bir sınıfın bir bağımlılığı varsa ve bu bağımlılık için test sınıfında ne bir @Mock ne de bir @Spy tanımlanmamışsa, Mockito o bağımlılığı enjekte edemez. Bu durumda, o alan genellikle null kalır (eğer temel bir tip değilse) veya varsayılan değerini alır. Bu, testlerinizde NullPointerException‘lara yol açabilir. Bu nedenle, @InjectMocks tarafından yönetilen bir sınıfın tüm bağımlılıklarının ya mock’lanmış ya da gerçek nesnelerle manuel olarak sağlanmış olduğundan emin olmalısınız.

@Spy ile Kısmi Mocking (Partial Mocking)

Bazen bir sınıfın gerçek metodlarının çoğunu kullanırken, sadece belirli metodlarını taklit etmek isteyebilirsiniz. Bu duruma “kısmi mocking” denir ve Mockito’da @Spy anotasyonu ile yapılır. @InjectMocks, @Mock gibi @Spy anotasyonlu bağımlılıkları da enjekte edebilir. Ancak, kısmi mocking genellikle karmaşıklığı artırdığı ve testleri daha kırılgan hale getirdiği için dikkatli kullanılmalıdır. Genellikle, bir sınıfın tüm bağımlılıklarını mock’lamak daha iyi bir yaklaşımdır.

Sonuç ve Sıkça Sorulan Sorular (SSS)

Mockito’nun @InjectMocks anotasyonu, birim testlerinizde bağımlılık enjeksiyonunu otomatikleştirerek test kurulumunu basitleştiren ve kodunuzu daha temiz hale getiren güçlü bir araçtır. @Mock ile birlikte kullanıldığında, test edilen sınıfın bağımlılıklarını kolayca taklit edebilir, böylece testlerinizin izole, hızlı ve deterministik olmasını sağlayabilirsiniz. Bu sayede, yazılımınızın kalitesini artırırken geliştirme sürecinizi hızlandırabilirsiniz.

Sıkça Sorulan Sorular (SSS)

1. @Mock ile @InjectMocks arasındaki temel fark nedir?
@Mock, bir bağımlılığın taklit edilmiş (sahte) bir örneğini oluşturur. Bu mock nesnesinin davranışlarını test senaryonuza göre belirlersiniz. @InjectMocks ise, test edilen sınıfın (SUT) gerçek bir örneğini oluşturur ve bu örneğin bağımlılıklarını, test sınıfında tanımlanmış @Mock veya @Spy anotasyonlu alanlardan otomatik olarak enjekte etmeye çalışır. Kısacası, @Mock bağımlılıkları yaratır, @InjectMocks ise bu bağımlılıkları SUT’a enjekte eder.

2. @InjectMocks manuel bağımlılık enjeksiyonuyla nasıl karşılaştırılır?
Manuel bağımlılık enjeksiyonunda, test edilen sınıfın bir örneğini kendiniz oluşturur ve bağımlılıklarını constructor, setter veya field aracılığıyla manuel olarak geçersiniz. Örneğin: UserService userService = new UserService(userRepositoryMock);. @InjectMocks bu boilerplate kodunu ortadan kaldırır. Otomatik olarak SUT’ı örneklendirir ve mevcut mock’ları enjekte eder, böylece test kodunuz daha kısa ve okunabilir olur.

3. @InjectMocks hangi enjeksiyon yöntemlerini destekler?
Mockito, @InjectMocks ile enjeksiyon yaparken sırasıyla şu yöntemleri dener: constructor enjeksiyonu, setter enjeksiyonu ve field enjeksiyonu. En uygun olanı bulduğunda enjeksiyonu gerçekleştirir.

4. @InjectMocks bir bağımlılığı enjekte edemezse ne olur?
Eğer @InjectMocks ile işaretlenmiş bir sınıfın bir bağımlılığı varsa ve bu bağımlılık için test sınıfında ne bir @Mock ne de bir @Spy tanımlanmamışsa, Mockito o bağımlılığı enjekte edemez. Bu durumda, ilgili alan genellikle null kalır ve bu durum testlerinizde NullPointerException‘lara yol açabilir.

5. Neden @InjectMocks kullanmalıyız?
@InjectMocks kullanmak, test kurulum kodunu azaltır, testlerinizi daha okunabilir hale getirir ve bağımlılık enjeksiyonu prensiplerine uygun kod yazmayı teşvik eder. Test edilen sınıfın bağımlılıklarını otomatik olarak yöneterek, test yazmaya odaklanmanızı sağlar ve testlerin bakımını kolaylaştırır.