[코드가 환경을 모르는 구조 6/7] 컨테이너는 왜 폭발하는가
0
AI 요약

이 글은 AI가 원문을 분석하여 핵심 내용을 요약한 것입니다.

이 게시물은 실제 DB에 붙는 통합 테스트가 느려지고 무시되는 원인으로 dirty context로 인한 Testcontainers 컨테이너 복제를 설명합니다. Spring TestContext 캐시는 @MockBean/@SpyBean, @DynamicPropertySource, TestConfiguration 등으로 컨텍스트 “모양” 키가 달라지면 재사용이 깨져 컨테이너도 새로 뜨게 함을 말합니다. @DirtiesContext는 컨텍스트 캐시를 명시 제거해 매 테스트가 새 컨텍스트/새 컨테이너를 만들게 만들며 모듈이 늘수록 곱셈으로 컨테이너 수가 폭증한다고 정리합니다. flex의 해법은 Mock으로 돌아가지 않고 실제 DB를 유지하되 컨테이너는 Gradle BuildService로 공유하고 격리는 논리 스키마 수준(모듈별 데이터베이스)으로 내리는 방식으로 제시합니다. Gradle BuildService는 빌드 전체에서 컨테이너를 한 번 기동하고 빌드 종료에 close()로 정리하며, JdbcTestContainerBuildService 추상으로 수명 관리와 접속 정보 노출을 플러그인에 맡긴다고 설명합니다. 모듈별로 파생한 데이터베이스 이름을 BuildService가 만들고 Liquibase가 각 모듈 changelog를 해당 DB에 적용해 동일 컨테이너 공유에도 재현성과 격리를 확보한다고 요약합니다. CI와 로컬에서 BuildService 재사용 범위가 달라질 수 있으며 후속 화에서 variant와 스냅샷 캐시를 다루겠다고 예고합니다.

연관 게시글