Spring Boot 테스트 코드 작성

영속성 계층 테스트: @DataJpaTest

@DataJpaTest는 기본적으로 내장 메모리 데이터베이스로 교체해 실행하고, 각 테스트를 트랜잭션으로 감싼 뒤 끝나면 롤백해 테스트 간 격리를 보장한다.

@DataJpaTest
class MemberRepositoryTest {

    @Autowired
    MemberRepository memberRepository;

    @Autowired
    TestEntityManager em;

    @Test
    void 이름으로_회원을_조회한다() {
        em.persist(new Member("김개발"));
        em.flush();
        em.clear();

        List<Member> result = memberRepository.findByName("김개발");

        assertThat(result).hasSize(1);
    }
}

flush와 clear로 영속성 컨텍스트를 비워야 1차 캐시가 아닌 실제 쿼리 실행을 검증할 수 있다는 점에 주의한다. 운영 데이터베이스와 같은 환경에서 검증하고 싶다면 @AutoConfigureTestDatabase(replace = Replace.NONE)와 Testcontainers를 조합해 실제 MySQL이나 PostgreSQL 컨테이너로 테스트한다. 방언(Dialect) 차이로 내장 데이터베이스에서만 통과하는 쿼리를 걸러낼 수 있기 때문이다.

컨텍스트 캐싱과 주의할 점

스프링 테스트 프레임워크는 같은 설정의 컨텍스트를 한 번만 띄우고 테스트 클래스 간에 재사용하는 컨텍스트 캐싱을 제공한다. 그런데 @MockitoBean 조합, @ActiveProfiles, properties 속성이 다르면 별도의 캐시 키가 되어 컨텍스트가 새로 뜬다. 테스트 클래스마다 설정이 제각각이면 빌드 시간에서 컨텍스트 기동이 큰 비중을 차지하게 되므로, 공통 설정을 추상 클래스나 메타 애너테이션으로 통일하는 것이 좋다. @DirtiesContext는 컨텍스트를 오염시켰을 때 캐시를 버리게 하는 장치이지만 남용하면 캐싱 이점이 사라진다.

실제 서버 구동이 필요한 경우에는 @SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)로 임의 포트에 서버를 띄우고 TestRestTemplate이나 WebTestClient로 호출한다. 고정 포트는 병렬 빌드에서 충돌하므로 피한다.

면접에서 이렇게 물어본다

• 단위 테스트, 슬라이스 테스트, 통합 테스트를 어떤 기준으로 나누어 작성하는지 설명해 보라.
• @WebMvcTest가 @SpringBootTest와 비교해 무엇을 로딩하고 무엇을 로딩하지 않는지 말해 보라.
• @DataJpaTest에서 flush와 clear를 호출하는 이유를 영속성 컨텍스트와 연결해 설명해 보라.
• 스프링 테스트의 컨텍스트 캐싱 동작과 캐시가 재사용되지 못하는 조건을 말해 보라.
• 내장 메모리 데이터베이스 대신 Testcontainers를 쓰는 이유를 설명해 보라.