Spring Test Dilimleri ve Context Cache

Testler yavaşlayınca akla ilk gelen, uygulamanın tamamı yerine yalnızca küçük bir parçasını açmak olur. Doğru yönde bir fikir — ama neden işe yaradığı çoğu zaman yanlış biliniyor.

Spring açtığını saklar

Spring test context’ini test sınıfı başına değil, yapılandırma başına oluşturur. Sekiz sınıf aynı annotation ve aynı ayarları kullanıyorsa context bir kez başlar, yedi kez cache’ten gelir.

Yani “sekiz @SpringBootTest sınıfı = sekiz uygulama başlatma” yanlıştır. Bu tek bilgi, suite süresini nereden düşüreceğini belirler.

Kendin gör

Sırayla dene ve ortadaki kutuya dikkat et:

1. Her şey @SpringBootTest. Toplam ~28 sn, tek context. Tek sınıfı çalıştırmak 14.4 sn.
2. Dilimlere geç. Toplam neredeyse aynı (~28 sn). Ama tek sınıf 2.9 sn — beş kat.
3. Dilimler + birim testi. Toplam 22 sn’ye düşüyor: servis testleri Spring’e hiç ihtiyaç duymuyor.
4. @MockitoBean anahtarını aç (1. kurulumda). Context 1’den 2’ye çıkıyor, süre +12 sn.
5. Testcontainers’ı aç. Veritabanına bağlanan her context ayrı konteyner başlatıyor.

Dilimler neyi açar?

Dilimin yüklemediği her bean @MockitoBean ile verilmelidir. @WebMvcTest içinde controller’ın çağırdığı servis mock’lanır — zaten test edilen şey controller’dır.

@DataJpaTest bir ek davranış daha getirir: her testi transaction içinde çalıştırır ve sonunda geri alır. Testler birbirinin verisini görmez.

Asıl kazanç: geri bildirim süresi. Simülatördeki ikinci adım dersin özeti. Toplam süre değişmedi ama tek sınıfı çalıştırmak 14.4 sn’den 2.9 sn’ye düştü.

Bir geliştirici gün içinde tüm suite’i birkaç kez, tek bir test sınıfını ise onlarca kez çalıştırır. Optimize edilmesi gereken sayı budur.

İkinci kazanç ölçülemez ama daha değerlidir: izolasyon. @WebMvcTest kırmızıysa web katmanı bozuktur. @SpringBootTest kırmızıysa her şey olabilir — ve hata ayıklama oradan başlar.

Tuzaklar: çok fazla farklı ayar

Cache anahtarı yapılandırmadır. Aşağıdakilerin her biri yeni bir context demektir:

1
@MockitoBean PaymentClient paymentClient;   // farklı bean grafiği
2
@ActiveProfiles("integration")              // farklı profil
3
@TestPropertySource(properties = "...")     // farklı property
4
@SpringBootTest(webEnvironment = RANDOM_PORT)  // farklı web ortamı

Otuz test sınıfının her biri kendi @MockitoBean kombinasyonunu kullanıyorsa, otuz kez uygulama başlatırsın. Suite’in on dakika sürmesinin sebebi @SpringBootTest değil, otuz farklı yapılandırmadır.

Pratik kural: mock kombinasyonlarını standartlaştır. Ortak bir @TestConfiguration veya bir temel sınıf, tüm entegrasyon testlerinin aynı context’i paylaşmasını sağlar.

İlginç bir sonuç: simülatörde 3. kurulumda @MockitoBean eklemek hiçbir şeye mal olmuyor — çünkü o context’i zaten tek bir sınıf kullanıyordu. Bean override’ın maliyeti override’ın kendisinde değil, paylaşılan bir context’i bölmesindedir.

Servis testlerine Spring gerekmez. En büyük kazanç aslında en basit olanı:

1
class PricingServiceTest {
2
  private final DiscountPolicy policy = mock(DiscountPolicy.class);
3
  private final PricingService service = new PricingService(policy);
4

5
  @Test
6
  void appliesDiscount() { ... }   // context yok, 10 ms
7
}

Constructor injection kullanıyorsan servis sınıfı düz bir Java nesnesidir. Onu test etmek için uygulama başlatmak, çekiç yerine vinç kullanmaktır.

Bu, field injection’dan kaçınmanın en somut gerekçesidir: @Autowired bir alana yazıldığında sınıfı Spring olmadan kuramazsın.

Testcontainers

H2 hızlıdır ama Postgres değildir. Farklı SQL lehçesi, farklı kilitleme davranışı, farklı tip sistemi — üretimde patlayan sorgu testte geçer.

Testcontainers gerçek veritabanını kullanır. Bedeli konteyner başlatma süresidir ve simülatörde bu açıkça görünür.

Çözüm, konteyneri context başına değil JVM başına bir kez başlatmaktır:

1
abstract class IntegrationTestBase {
2
  static final PostgreSQLContainer<?> DB = new PostgreSQLContainer<>("postgres:16");
3

4
  static { DB.start(); }   // bir kez başlar, JVM kapanınca Ryuk temizler
5

6
  @DynamicPropertySource
7
  static void props(DynamicPropertyRegistry registry) {
8
    registry.add("spring.datasource.url", DB::getJdbcUrl);
9
  }
10
}

Bu desen aynı zamanda tüm entegrasyon testlerini tek bir temel sınıfta toplayarak context sayısını da düşürür — iki sorunu birden çözer.

Bir banka hesap servisinde bu katmanlar nasıl yan yana durur, bakalım. Her test yalnızca ihtiyaç duyduğu kadarını açıyor.

1
@WebMvcTest(AccountController.class)
2
class AccountControllerTest {
3

4
    @Autowired
5
    MockMvc mvc;
6

7
    @MockitoBean
8
    AccountService accounts;
9

10
    @Test
11
    @WithMockUser("C-1001")
12
    void returnsBalanceWithCurrency() throws Exception {
13
        when(accounts.balance("C-1001", "TR330006100519786457841326"))
14
                .thenReturn(new Money(new BigDecimal("1250.40"), Currency.getInstance("TRY")));
15

16
        // Amounts travel as strings, so no client ever parses them into a double.
17
        mvc.perform(get("/accounts/TR330006100519786457841326/balance"))
18
                .andExpect(status().isOk())
19
                .andExpect(jsonPath("$.amount").value("1250.40"))
20
                .andExpect(jsonPath("$.currency").value("TRY"));
21
    }
22
}

1
public abstract class PostgresTestBase {
2

3
    // One container per JVM; Ryuk removes it when the JVM exits.
4
    static final PostgreSQLContainer<?> DB = new PostgreSQLContainer<>("postgres:16");
5

6
    static {
7
        DB.start();
8
    }
9

10
    @DynamicPropertySource
11
    static void datasource(DynamicPropertyRegistry registry) {
12
        registry.add("spring.datasource.url", DB::getJdbcUrl);
13
        registry.add("spring.datasource.username", DB::getUsername);
14
        registry.add("spring.datasource.password", DB::getPassword);
15
    }
16
}

1
@DataJpaTest
2
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)   // keep the real Postgres
3
class LedgerEntryRepositoryTest extends PostgresTestBase {
4

5
    private static final String IBAN = "TR330006100519786457841326";
6

7
    @Autowired
8
    LedgerEntryRepository ledger;
9

10
    @Test
11
    void balanceIsCreditsMinusDebits() {
12
        ledger.save(LedgerEntry.credit(IBAN, new BigDecimal("1000.00"), "TRY"));
13
        ledger.save(LedgerEntry.debit(IBAN, new BigDecimal("249.60"), "TRY"));
14

15
        assertThat(ledger.balanceOf(IBAN, "TRY")).isEqualByComparingTo("750.40");
16
    }
17
}

1
class TransferServiceTest {
2

3
    private static final String FROM = "TR330006100519786457841326";
4
    private static final String TO = "TR360001000123456789012345";
5

6
    private final LedgerEntryRepository ledger = mock(LedgerEntryRepository.class);
7
    private final TransferService transfers = new TransferService(ledger);
8

9
    @Test
10
    void refusesATransferAboveTheBalance() {
11
        when(ledger.balanceOf(FROM, "TRY")).thenReturn(new BigDecimal("100.00"));
12

13
        assertThatThrownBy(() -> transfers.send(FROM, TO, new BigDecimal("150.00"), "TRY"))
14
                .isInstanceOf(InsufficientFundsException.class);
15
        verify(ledger, never()).save(any());
16
    }
17
}

Kendini sına