Testcontainers — Gerçek Veritabanı, Tek Konteyner, Kilitli Kapı

Testlerin bilgisayarında hep yeşil. Sorgu canlıda ilk gün patlıyor, çünkü testler başka bir veritabanında koşuyordu. Bu derste testlere gerçeğini vereceğiz ve bunu yaparken düşülen küçük bir çukuru göreceğiz.

Neden gerçek veritabanı?

H2 gibi bellekteki bir veritabanı hızlıdır ama PostgreSQL değildir. ON CONFLICT, jsonb ya da kilitleme davranışı farklıdır. Testte geçen sorgu canlıda patlayabilir.

Testcontainers?Terimin tanımını açTestcontainersTest sırasında Docker'da gerçek bağımlılıklar (PostgreSQL, Kafka, Redis) başlatan kütüphane. Testler canlıdaki yazılımın aynısıyla koşar.Sözlükte gör → test sırasında Docker’da gerçek bir PostgreSQL başlatır. Testler, canlıdaki veritabanının aynı sürümüyle konuşur.

İki ayrı hafıza

Spring, kurduğu uygulama context’ini bir context cache?Terimin tanımını açcontext cacheSpring'in test bağlamlarını yapılandırmaya göre önbelleğe alması. Anahtar anotasyonlar, property'ler, profiller ve mock'lardır — bir `@MockBean` farkı yeni bir bağlam demektir.Sözlükte gör →’te saklar. Aynı ayarlarla çalışan bir sonraki test sınıfı yeni context kurmaz, cache’tekini kullanır.

Testcontainers’ın JUnit eklentisi ise @Container ile işaretli statik bir konteyneri her test sınıfının başında başlatır, sonunda durdurur. İki sistem de kendi işini doğru yapıyor, ama birbirinden habersiz.

Bir kez başlat

İlk yol: konteyneri taban sınıfta @Container olmadan, statik bir blokta bir kez start() ile başlatırsın. JVM kapanınca Testcontainers’ın temizlik konteyneri onu kaldırır.

İkinci yol, Spring Boot 3.1 ile geldi: konteyneri ortak bir test ayarında bean olarak tanımlar, üstüne @ServiceConnection?Terimin tanımını aç@ServiceConnectionSpring Boot 3.1 ile gelen işaret: bir konteyner bean'inin adresini ve kimlik bilgilerini bağlantı ayarlarına kendiliğinden yazar.Sözlükte gör → yazarsın. Bağlantı ayarları kendiliğinden verilir ve konteyner, context yaşadıkça yaşar.

Kendin gör

1. Varsayılanla oynat. Her sınıf kendi konteynerini ve kendi context’ini kurdu: dört ve dört.
2. “Ortak taban sınıf, @Container” seç. İlk sınıf geçti, diğerleri eski porta çarptı.
3. “Statik blokta start()” seç. Bir konteyner, bir context, hepsi geçti.
4. “@ServiceConnection bean” seç. Aynı sonuç, daha az kod.

Tuzaklar

Paylaşılan veri. Bütün sınıflar aynı veritabanını kullanır. Bir testin bıraktığı satır diğerini şaşırtır; her test kendi verisini kursun ya da transaction içinde geri alınsın.

latest etiketi. postgres:latest bir gün sessizce yeni bir ana sürüme geçer. Canlıdaki sürümü sabit yaz: postgres:16-alpine gibi.

Docker’sız makine. CI’da Docker yoksa testler başlamaz. Bu bir test hatası değil, ortam eksiği; CI’ı buna göre kur.

Aşağıdaki örnek bir bankanın hesap servisinden: bütün entegrasyon testleri tek PostgreSQL konteynerini ve tek Spring context’ini paylaşıyor.

1
@TestConfiguration(proxyBeanMethods = false)
2
public class PostgresTestConfig {
3

4
    // Same major version as production. Never "latest".
5
    @Bean
6
    @ServiceConnection   // Boot fills spring.datasource.* from the running container
7
    PostgreSQLContainer<?> postgres() {
8
        return new PostgreSQLContainer<>("postgres:16-alpine");
9
    }
10
}

1
@SpringBootTest
2
@Import(PostgresTestConfig.class)   // same annotations + same import everywhere -> same cached context
3
@Transactional
4
class AccountRepositoryIT {
5

6
    @Autowired AccountRepository accounts;
7

8
    @Test
9
    void upsertKeepsOneRowPerIban() {
10
        accounts.upsertBalance("TR330006100519786457841326", new BigDecimal("10.00"));
11
        accounts.upsertBalance("TR330006100519786457841326", new BigDecimal("25.00"));
12

13
        assertThat(accounts.count()).isEqualTo(1);   // ON CONFLICT: a Postgres feature H2 lacks
14
    }
15
}

1
@SpringBootTest
2
@Import(PostgresTestConfig.class)
3
@Transactional          // every test rolls back: the shared database stays clean
4
class TransferServiceIT {
5

6
    @Autowired TransferService transfers;
7
    @Autowired AccountRepository accounts;
8

9
    @Test
10
    void movesMoneyBetweenTwoAccounts() {
11
        long from = accounts.save(Account.open("TR01", new BigDecimal("100.00"))).getId();
12
        long to = accounts.save(Account.open("TR02", BigDecimal.ZERO)).getId();
13

14
        transfers.transfer(from, to, new BigDecimal("40.00"));
15

16
        assertThat(accounts.findById(to).orElseThrow().balance()).isEqualByComparingTo("40.00");
17
    }
18
}

1
// Run the real app against a throwaway Postgres: ./gradlew bootTestRun
2
public class LocalAccountApp {
3

4
    public static void main(String[] args) {
5
        SpringApplication.from(AccountApplication::main)
6
                .with(PostgresTestConfig.class)
7
                .run(args);
8
    }
9
}

1
// The pattern from the sim that fails: JUnit stops this container after every
2
// subclass and starts a new one on a new port, while Spring hands the next
3
// class the cached context that still points at the old port.
4
@Testcontainers
5
abstract class AvoidThisBase {
6

7
    @Container
8
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:16-alpine");
9

10
    @DynamicPropertySource
11
    static void props(DynamicPropertyRegistry registry) {
12
        registry.add("spring.datasource.url", postgres::getJdbcUrl);
13
    }
14
}

Kendini sına