Java Test코드 작성 @Transactional 테스트 격리의 딜레마

Java와 Spring으로 테스트 코드를 작성할 때, 우리는 아주 자연스럽게 테스트 클래스 상단에 @Transactional을 붙이곤 한다.

이 어노테이션 하나만 있으면 테스트가 끝난 후 자동으로 Rollback이 되므로, 데이터베이스에 쓰레기 데이터가 남지 않고 각 테스트의 독립성(Isolation)을 아주 쉽게 보장받을 수 있기 때문이다.

하지만 이 편리함 뒤에는 "거짓된 초록불(Green Light)"이라는 치명적인 함정이 숨어 있다.

@Transactional의 달콤한 유혹

우리가 테스트 클래스에 @Transactional을 습관적으로 사용하는 이유는 명확하다.

1. 편리함: setUp이나 tearDown에서 데이터를 일일이 지울 필요가 없다.
2. 속도: 실제로 DB에 커밋하지 않고 롤백하므로, 테이블을 Truncate하거나 DELETE 쿼리를 날리는 I/O 비용보다 빠를 수 있다.

하지만 이 "테스트 환경만의 트랜잭션"은 실제 프로덕션 코드와 다른 환경을 만들어낸다.

함정 1: 프로덕션 코드의 @Transactional 누락 감지 불가

가장 흔하면서도 위험한 시나리오다. 개발자가 실수로 서비스 레이어에 @Transactional을 붙이지 않았다고 가정해 보자.

결국 개발자는 **"테스트 통과했으니 배포하자!"**라고 생각하지만, 배포 후 런타임 에러를 마주하게 된다.

함정 2: 영속성 컨텍스트(Persistence Context)의 생명주기 불일치

JPA를 사용할 때 이 문제는 더 두드러진다. 특히 지연 로딩(Lazy Loading)과 관련된 문제다.

// Service Code
public void logic() {
    Member member = memberRepository.findById(1L);
    // @Transactional이 없다면 여기서 영속성 컨텍스트가 종료됨
    member.getTeam().getName(); // Lazy Loading 시도 -> 예외 발생! (LazyInitializationException)
}

• 프로덕션: 트랜잭션이 없다면 findById 이후 세션이 닫혀서, getTeam()을 호출할 때 LazyInitializationException이 발생한다.
• 테스트(@Transactional): 테스트 메서드가 끝날 때까지 영속성 컨텍스트가 살아있다. 지연 로딩이 아주 잘 동작한다. 즉, 잘못된 코드를 성공으로 둔갑시킨다.

해결책: tearDown(@AfterEach)을 통한 수동 삭제

이러한 "환경의 불일치"를 막기 위해, 통합 테스트에서는 @Transactional을 제거하고 데이터 클렌징 작업을 수동으로 수행하는 것이 권장된다.

이 방식을 사용하면 테스트 환경을 실제 프로덕션 환경과 가장 유사하게(Clean하게) 유지할 수 있다.

구현 예시

@SpringBootTest
class MemberServiceTest {

    @Autowired MemberRepository memberRepository;
    @Autowired MemberService memberService;

    @AfterEach // tearDown
    void tearDown() {
        // 모든 데이터를 삭제하여 다음 테스트에 영향을 주지 않도록 한다
        memberRepository.deleteAllInBatch();
    }

    @Test
    void 회원가입_테스트() {
        // Given
        Member member = new Member("userA");

        // When
        // 만약 join 내부에 @Transactional이 없다면?
        // -> 여기서 바로 예외가 터지거나 DB 반영이 안 되어 테스트가 실패한다 (버그 조기 발견!)
        memberService.join(member);

        // Then
        assertThat(memberRepository.findAll()).hasSize(1);
    }
}

tearDown 방식의 장점

1. 거짓 양성 제거: 프로덕션 코드에 @Transactional이 없으면 테스트가 정직하게 실패한다.
2. 지연 로딩 검증: 영속성 컨텍스트가 서비스 메서드 단위로 정확히 닫히므로, LazyInitializationException 발생 여부를 정확히 테스트할 수 있다.
3. 현실적인 환경: 롤백에 의존하지 않고 실제로 DB에 INSERT, DELETE를 수행하므로 제약 조건(Constraints) 등을 더 확실하게 검증한다.

요약: 언제 무엇을 써야 할까?

무조건 @Transactional을 쓰지 말라는 것은 아니다. 상황에 맞게 선택해야 한다.