[테스트] 통합 테스트에서 테스트 간 DB 상태가 공유되는 문제 : @Transactional, 사용하면 안되는 상황, 그외 방식

상황

- 아래 테스트 코드를 실행 시켰다 

@SpringBootTest
@Import(SplearnTestConfiguration.class)
public class MemberRegisterTest {
  @Autowired
  private MemberRegister memberRegister;

  @Test
  void register(){
    Member member = memberRegister.register(MemberFixture.createRegisterRequest());

    assertThat(member.getId()).isNotNull();
    assertThat(member.getStatus()).isEqualTo(MemberStatus.PENDING);
  }

  @Test
  void duplicateEmailFail(){
    Member member = memberRegister.register(MemberFixture.createRegisterRequest());

    assertThatThrownBy(
        () -> memberRegister.register(MemberFixture.createRegisterRequest())
    ).isInstanceOf(DuplicateEmailException.class);

  }
}

 

현상

duplicateEmailFail의 첫번째 register에서 예외가 발생했다 

 

원인

통합 테스트에서 테스트 간 DB 상태가 공유되는 것이 문제였다.

 

해결

따라서, @Transactional 으로 테스트 메서드마다 실행 후 자동 롤백되도록 한다. 

 

---

@Transactional 으로 롤백이 안되는 경우는 없을까?

1. 스프링 테스트가 아닐 때 

Spring Test의 TransactionalTestExecutionListener가 @Transactional의 테스트 후 자동 롤백을 해준다. 

2. HTTP 레벨 테스트 

@SpringBootTest(webEnvironment=RANDOM_PORT) + RestTemplate/WebTestClient로 테스트하면 

서버가 별도 스레드에서 별도 트랜잭션을 사용하므로,

테스트의 롤백이 서버 쪽 DB 변경에 영향을 못 준다.

 

3. DB가 원격이거나 분리된 경우 

테스트의 애플리케이션이 서로 다른 DB 커넥션/트랜잭션을 사용하면 롤백이 불가능하다 

 

---

테스트 코드와 애플리케이션 코드가 같은 트랜잭션을 공유하면 안되는 경우가 있을까?

@Transactional 테스트가 버그를 숨기는 경우 

1) Lazy Loading 문제

 

- 테스트에 @Transactional이 있으면 영속성 컨텍스트가 테스트 끝까지 열려있음

- 서비스에서 지연 로딩(LAZY)을 호출해도 테스트에선 정상 동작

- 하지만 실제 운영에선 서비스 메서드가 끝나면 트랜잭션이 닫히므로 LazyInitializationException 발생

- 테스트는 통과했는데 운영에서 터지는 상황

// Member 엔티티
@Entity
public class Member {
  @OneToMany(fetch = FetchType.LAZY)
  private List<Order> orders;  // 지연 로딩
}

// 서비스
@Service
public class MemberService {
  @Transactional
  public Member findMember(Long id) {
    return memberRepository.findById(id).orElseThrow();
    // 여기서 트랜잭션 끝 → 영속성 컨텍스트 닫힘
  }
}

 

// 테스트에 @Transactional이 있으면
@Test
@Transactional
void test() {
  Member member = memberService.findMember(1L);
  member.getOrders().size(); // 테스트 트랜잭션이 아직 열려있어서 → 성공!
}

// 운영에서는
Member member = memberService.findMember(1L);
member.getOrders().size(); // 서비스 트랜잭션이 이미 닫혔으므로 → LazyInitializationException!

 

 

 운영 환경                                                                                      
  컨트롤러 호출                                                                                  
    → 서비스 @Transactional 시작 → 영속성 컨텍스트 열림                                          
      → memberRepository.findById(1L)  -- Member 로딩 (orders는 LAZY라 프록시)                   
    → 서비스 @Transactional 끝 → 영속성 컨텍스트 닫힘

    → member.getOrders().size()  -- 영속성 컨텍스트 이미 닫힘 → LazyInitializationException!

  테스트 환경 (@Transactional 있을 때)
  테스트 @Transactional 시작 → 영속성 컨텍스트 열림
    → 서비스 @Transactional (테스트 트랜잭션에 합류, 새로 안 만듦)
      → memberRepository.findById(1L)
    → 서비스 메서드 끝 (하지만 트랜잭션은 테스트 것이라 안 닫힘)

    → member.getOrders().size()  -- 테스트 트랜잭션이 아직 열려있음 → 성공!
  테스트 @Transactional 끝 → 롤백

  핵심은 서비스의 @Transactional이 독립 트랜잭션을 안 만들고 테스트 트랜잭션에 합류(기본 전파 =
  REQUIRED)하기 때문에, 서비스 메서드가 끝나도 영속성 컨텍스트가 살아있다.

운영에서는 서비스 트랜잭션이 진짜 끝나니까 터진다.

 

 

2) Flush 타이밍 문제 (ID 생성 전략에 따라 다름)

 

- 롤백할 거니까 JPA가 DB에 flush를 안 할 수 있음

    GenerationType.IDENTITY는 save()시 즉시 INSERT 실행

    GenerationType.SEQUENCE는 save()시 INSERT를 커밋 시점까지 미룰 수 있음 -> 이때 flush 생략 가능

- unique 제약 조건 위반 같은 DB 레벨 에러가 테스트에서 안 터짐

- 테스트는 통과, 운영에서 실패 

 

예를 들어, 아래처럼 @Id의 @GeneratedValue(GenerationType.SEQUENCE)인 엔티티가 있고

@Entity
public class Member {
	@Id
  	@GeneratedValue(strategy = GenerationType.SEQUENCE) // 확인!
  	private Long id;
    
    // Member 엔티티에 unique 제약
	@Column(unique = true)
	private String email;
    
    //중략..
}

 

아래와 같은 @DataJpaTest 테스트 코드를 작성한다고 하자 

@DataJpaTest
class MemberRepositoryTest {
  @Autowired
  MemberRepository memberRepository;
  
  // @Transactional - @DataJpaTest을 사용하게 되면 @Transactional이 이미 포함되어 있음
  @Test
  void duplicateEmailFail(){
    Member member = Member.register(createRegisterRequest(), createPasswordEncoder());
    memberRepository.save(member);

    Member member2 = Member.register(createRegisterRequest(), createPasswordEncoder());
    assertThatThrownBy(() -> memberRepository.save(member2))
        .isInstanceOf(DataIntegrityViolationException.class);

  }
}

 

2번째 save에서 예외가 났어야 했지만, 

로그를 살펴보면, SEQUENCE 전략은 시퀀스에서 id만 미리 받아오고,

실제 INSERT는 flush/커밋 시점까지 미루기 때문에,

unique 제약 위반이 발생하지 않음을 알 수 있다. (IDENTITY는 flush되서 예외 발생함)

Hibernate: create sequence member_seq start with 1 increment by 50
Hibernate: create table member (id bigint not null, address varchar(255), nick_name varchar(255), password_hash varchar(255), status enum ('ACTIVE','DEACTIVATED','PENDING'), primary key (id), unique (address))
2026-02-09T21:44:16.147+09:00  INFO 10145 --- [splearn] [    Test worker] j.LocalContainerEntityManagerFactoryBean : Initialized JPA EntityManagerFactory for persistence unit 'default'
2026-02-09T21:44:16.276+09:00  INFO 10145 --- [splearn] [    Test worker] t.s.a.required.MemberRepositoryTest      : Started MemberRepositoryTest in 0.878 seconds (process running for 1.221)
Mockito is currently self-attaching to enable the inline-mock-maker. This will no longer work in future releases of the JDK. Please add Mockito as an agent to your build what is described in Mockito's documentation: https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#0.3
WARNING: A Java agent has been loaded dynamically (/Users/eundms/.gradle/caches/modules-2/files-2.1/net.bytebuddy/byte-buddy-agent/1.15.11/a38b16385e867f59a641330f0362ebe742788ed8/byte-buddy-agent-1.15.11.jar)
WARNING: If a serviceability tool is in use, please run with -XX:+EnableDynamicAgentLoading to hide this warning
WARNING: If a serviceability tool is not in use, please run with -Djdk.instrument.traceUsage for more information
WARNING: Dynamic loading of agents will be disallowed by default in a future release
Hibernate: select next value for member_seq // 첫 번째 save: 시퀀스 값만 가져옴
Hibernate: select next value for member_seq // 두 번째 save: 시퀀스 값만 가져옴

Expecting code to raise a throwable.
java.lang.AssertionError: 
Expecting code to raise a throwable.
at tobyspring.splearn.application.required.MemberRepositoryTest.duplicateEmailFail(MemberRepositoryTest.java:38)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)

Hibernate: insert into member (address,nick_name,password_hash,status,id) values (?,?,?,?,?) //  실제 INSERT는 flush/커밋 시점까지 미룸

하지만, 운영에서 동일한 이메일을 두 번 입력하는 코드는 트랜잭션 커밋 시점에 flush 되어 예외가 발생한다 

// 운영에서는
memberRepository.save(new Member("a@b.com"));
memberRepository.save(new Member("a@b.com"));
// 트랜잭션 커밋 시점에 flush → DB에서 unique constraint violation!

 

 

즉, 다시 설명하자면, 

                                                                                              
  운영 환경 (트랜잭션 분리)                                                                      
  서비스 @Transactional 시작                                 
    → save(member1)   -- 시퀀스 조회                                                             
    → save(member2)   -- 시퀀스 조회                                                             
    → 트랜잭션 커밋 → flush → INSERT 2건 → unique 위반 터짐!

  테스트 환경 (트랜잭션 공유)
  테스트 @Transactional 시작 (= 서비스도 이 트랜잭션에 참여)
    → save(member1)   -- 시퀀스 조회
    → save(member2)   -- 시퀀스 조회
    → 테스트 끝 → 롤백 → flush 안 함 → unique 위반 안 터짐!

  테스트가 트랜잭션을 감싸고 있으니까, 서비스의 @Transactional이 새 트랜잭션을 안 만들고 테스트
  트랜잭션에 합류한다. 그러면 커밋이 영원히 안 일어나고(롤백이니까), flush도 생략될 수 있어서
  운영에서만 터지는 버그를 숨기게 된다.

 

 

// 참고로 SEQUENCE 를 예외 터지게 하려면 명시적으로 Flush 해줘야 함

  @Test
  void duplicateEmailFail(){
      Member member = Member.register(createRegisterRequest(), createPasswordEncoder());
      memberRepository.save(member);

      Member member2 = Member.register(createRegisterRequest(), createPasswordEncoder());
      memberRepository.save(member2);

      assertThatThrownBy(() -> entityManager.flush())  // 여기서 실제 INSERT 발생 → 예외
          .isInstanceOf(DataIntegrityViolationException.class);
  }

 

 

>>> 실제 운영 환경과 동일한 트랜잭션 경계로 테스트하고 싶을 때는 @Transactional을 빼고 테스트를 진행하자 

 

 

---

그렇다면, 테스트 간  데이터를 격리시키는 다른 방법에는 무엇이 있을까?

1) 각 테스트 마다 다른 데이터 사용하기 

2) 각 테스트 실행전에 데이터 초기화

 

언제 해야 할까?

- 각 테스트 시작 전 : @BeforeEach에서 정리 

 

어떻게 초기화해야 할까?

- @Sql / 로직 호출로 각 테스트에 적합한 데이터 입력 

- 메타 데이터에서 전체 테이블 목록을 자동으로 조회해서 TRUNCATE하는 클래스를 만들어두고 호출