테스트 간 데이터 격리는 어떻게 보장해야 할까요?

[softmoca]

테스트를 작성하다 보면 각 테스트가 독립적으로 실행되어야 한다는 이야기를 자주 듣습니다.

하지만 실제로는 이전 테스트에서 저장한 데이터가 다음 테스트에 영향을 주거나,
테스트 실행 순서에 따라 성공/실패가 달라지는 문제가 생길 수 있습니다.

예를 들어 예약 생성 테스트에서 저장한 데이터가 남아 있다면,
다음 테스트의 중복 예약 검증이나 전체 조회 결과에 영향을 줄 수 있습니다.

이를 막기 위해 여러 방법을 사용할 수 있을 것 같습니다.

1. 테스트마다 트랜잭션을 롤백한다.
2. @DirtiesContext로 컨텍스트를 새로 띄운다.
3. 테스트 전후로 테이블을 초기화한다.
4. 테스트마다 고유한 데이터를 사용한다.

각 방식은 테스트 격리에는 도움이 되지만,
속도, 유지보수성, 테스트 신뢰도 측면에서 서로 다른 트레이드오프가 있을 것 같습니다.

그렇다면 테스트 간 데이터 격리는 어떤 방식으로 보장하는 것이 좋을까요?
그리고 테스트가 서로 독립적이라는 것을 어떤 기준으로 판단할 수 있을까요?

[softmoca]

저는 테스트 간 데이터 격리의 본질이
각 테스트가 다른 테스트의 존재를 몰라도 항상 같은 결과를 내도록,
알려진 초기 상태에서 시작하게 만드는 것이라고 생각합니다.

격리가 깨지면 테스트가 실행 순서에 의존하게 되고,
혼자 돌리면 통과하는데 전체로 돌리면 실패하는 가장 추적하기 어려운 종류의 실패가 생깁니다.

그래서 저는 격리를 "테스트가 끝나고 청소하는 문제"가 아니라,
'각 테스트가 자기만의 깨끗한 출발점을 어떻게 보장받을 것인가'의 문제로 보고,
그 방법마다 보장 범위와 함정이 다르다고 생각합니다.

1. 데이터 격리가 깨지면 무슨 일이 일어나는가

저는 이 문제의 심각성을 먼저 짚고 싶습니다. 격리가 깨진 테스트는 가장 디버깅하기 어려운 실패를 만들기 때문입니다.

@Test
void 예약_목록_조회시_2건이_나온다() {
    예약_2건_저장();
    assertThat(repository.findAll()).hasSize(2);  // 혼자 돌리면 통과
}

이 테스트는 혼자 실행하면 통과합니다. 하지만 다른 테스트가 먼저 예약을 1건 저장하고 정리하지 않았다면, 전체 실행 시 findAll()이 3건을 반환해 실패합니다.

이때 나타나는 증상들이 격리 문제의 특징입니다.

• 혼자 돌리면 통과, 전체로 돌리면 실패 (또는 그 반대)
• 실행 순서를 바꾸면 결과가 달라짐
• 어제는 통과했는데 오늘은 실패 (테스트가 추가되면서 순서가 바뀜)

이전 토론들에서 강조했던 리팩터링 내성과 신뢰성이 모두 무너지는 지점입니다.

테스트가 실패해도 "진짜 버그인가, 격리 문제인가"를 의심하게 되면, 테스트 전체에 대한 신뢰가 무너집니다.

그래서 저는 격리를 "있으면 좋은 것"이 아니라 테스트가 신뢰를 가지기 위한 전제 조건이라고 생각합니다.

2. 격리의 두 가지 의미 — 상태 격리와 순서 독립

저는 "격리"라는 말이 사실 두 가지를 담고 있다고 생각합니다.

(a) 상태 격리

한 테스트가 만든 데이터가 다른 테스트에 보이지 않는다.

(b) 순서 독립

테스트가 어떤 순서로 실행되든 같은 결과를 낸다.

이 둘은 연결되어 있습니다. 상태가 제대로 격리되면 순서에 독립적이 되고, 순서에 의존한다는 건 상태 격리가 깨졌다는 신호입니다.

핵심 원칙은 각 테스트는 알려진 초기 상태에서 시작해야 한다는 것입니다.

이전 테스트가 무엇을 남겼는지 몰라도, 내 테스트는 항상 동일한 출발점을 가져야 합니다.

이걸 보장하는 방법이 아래에서 다룰 여러 전략들입니다.

3. 방법 1 — @transactional 롤백

가장 흔한 방법입니다. 테스트 메서드에 @Transactional을 붙이면 테스트가 끝날 때 Spring이 자동으로 롤백합니다.

@SpringBootTest
@Transactional
class ReservationServiceTest {
    @Test
    void 예약을_생성한다() {
        reservationService.create(요청);
        // 테스트 종료 시 자동 롤백 → DB에 흔적이 남지 않음
    }
}

장점

• 빠르다 (실제 삭제 없이 롤백)
• 코드가 간결하다
• 테스트마다 깨끗한 상태가 보장된다

함정 — 이게 핵심입니다

저는 테스트의 @Transactional 롤백이 편리하지만 위험한 양날의 검이라고 생각합니다. 이전 @Transactional 동작 원리 토론과 연결되는 지점입니다.

함정 (a) 실제 커밋 동작을 검증하지 못한다

테스트가 롤백되므로, 실제 운영에서 커밋될 때 일어나는 일을 못 봅니다. 예를 들어 커밋 시점에 동작하는 제약 조건, flush 타이밍 문제, 커밋 후 이벤트 같은 것을 놓칠 수 있습니다.

함정 (b) 트랜잭션 전파를 검증할 수 없다

테스트 전체가 하나의 트랜잭션으로 묶이므로, Service의 트랜잭션 경계가 의도대로 동작하는지 검증하기 어렵습니다.

이번 미션처럼 "예약 취소 → 첫 대기 승격"을 한 트랜잭션으로 묶었을 때, 중간 실패 시 롤백되는지를 테스트 @Transactional이 가려버릴 수 있습니다.

함정 (c) 동시성 테스트에서 무력하다

여러 스레드로 동시 요청을 보내는 테스트는, 테스트 스레드의 트랜잭션과 별개로 동작하므로 @Transactional 롤백이 동시성으로 생긴 데이터를 정리하지 못합니다.

그래서 저는 단순 CRUD나 도메인 검증에는 @Transactional 롤백이 편하지만, 트랜잭션 경계 자체나 동시성을 검증하는 테스트에는 쓰면 안 된다고 생각합니다.

4. 방법 2 — 매번 데이터 초기화 (truncate / @SQL)

테스트 전후로 테이블을 비우거나 초기 데이터를 다시 세팅하는 방법입니다.

@SpringBootTest
class ReservationIntegrationTest {
    @BeforeEach
    void cleanUp() {
        // 모든 테이블 truncate
        jdbcTemplate.execute("TRUNCATE TABLE reservation");
        jdbcTemplate.execute("ALTER TABLE reservation AUTO_INCREMENT = 1");
    }
}

또는 @Sql로 스크립트를 실행합니다.

@Sql(scripts = "/cleanup.sql", executionPhase = BEFORE_TEST_METHOD)

장점

• 실제로 커밋된 데이터를 검증할 수 있다 (롤백의 함정이 없다)
• 동시성 테스트에서도 동작한다
• 운영과 가장 가까운 방식

함정

함정 (a) 느리다

매번 실제 삭제·재삽입이 일어나므로 롤백보다 느립니다. 테스트가 많아질수록 누적됩니다.

함정 (b) 외래키 순서 문제

테이블을 truncate할 때 외래키 제약 때문에 순서가 중요합니다. 자식 테이블부터 지워야 하고, 안 그러면 제약 위반이 납니다. 또는 외래키 체크를 잠시 끄는 처리가 필요합니다.

함정 (c) AUTO_INCREMENT 초기화 누락

테이블만 비우고 AUTO_INCREMENT를 리셋하지 않으면, ID가 1이 아니라 이어집니다.

"생성된 예약의 ID는 1이다" 같은 테스트가 깨집니다.

저는 이 함정을 직접 실험해보면 격리의 의미를 가장 명확하게 체감할 수 있다고 생각합니다.

5. 방법 3 — 각 테스트가 자기 데이터를 명시적으로 만든다

전역 초기 데이터에 의존하지 않고, 각 테스트가 필요한 데이터를 그 안에서 직접 생성하는 방식입니다.

@Test
void 본인_예약만_조회된다() {
    Member 모카 = memberRepository.save(회원("moca"));
    Member 손손 = memberRepository.save(회원("songsong"));
    reservationRepository.save(예약(모카));
    reservationRepository.save(예약(손손));
    
    assertThat(reservationService.findByMember(모카.getId())).hasSize(1);
}

장점

• 테스트가 자기완결적이다 (다른 테스트의 초기 데이터를 몰라도 됨)
• 테스트만 봐도 무슨 데이터로 검증하는지 명확하다
• 전역 픽스처에 대한 암묵적 의존이 사라진다

함정

함정 (a) "특정 개수"에 의존하는 검증이 위험하다

findAll().hasSize(2)처럼 전체 개수를 단정하면, 다른 데이터가 섞일 때 깨집니다.

그래서 가능하면 contains, filteredOn처럼 내가 만든 데이터를 특정해서 검증하는 편이 격리에 강합니다.

함정 (b) 여전히 cleanup이 필요할 수 있다

데이터를 명시적으로 만들어도, 테스트가 끝난 뒤 정리하지 않으면 다음 테스트의 findAll에 영향을 줍니다.

그래서 이 방법도 보통 롤백이나 truncate와 함께 씁니다.

6. 격리 단위를 어디까지 가져갈 것인가

저는 격리를 고민할 때 어느 범위까지 격리할 것인가도 함께 생각해야 한다고 봅니다.

메서드 단위 격리

각 @Test마다 깨끗한 상태. 가장 안전하지만 가장 비쌈.

클래스 단위 픽스처 공유

@BeforeAll로 공통 데이터를 한 번만 세팅. 빠르지만 테스트끼리 데이터를 공유하므로 한 테스트가 데이터를 변경하면 다른 테스트가 영향받음 → 격리가 약해짐.

저는 변경(쓰기)이 있는 테스트는 반드시 메서드 단위로 격리하고, 읽기 전용이고 절대 안 바뀌는 데이터(예: 고정된 코드성 데이터)만 클래스 단위로 공유하는 편이 좋다고 생각합니다.

쓰기 테스트를 픽스처 공유로 묶으면 거의 반드시 격리 사고가 납니다.

7. 실험으로 확인해볼 것

저는 격리야말로 직접 실험으로 깨봐야 본질이 보인다고 생각합니다.

이전 격리 수준 토론에서 "이론을 현실에 대입하는 건 실험뿐"이라고 했던 것과 같은 맥락입니다.

해볼 만한 실험들:

실험 1. 일부러 격리를 깨본다

• @Transactional 없이, cleanup 없이 두 테스트를 작성하고 전체 실행 → 실패하는 걸 관찰
• 실행 순서를 바꿔보고 결과가 달라지는 걸 관찰

실험 2. AUTO_INCREMENT 함정 재현

• truncate만 하고 AUTO_INCREMENT를 리셋하지 않은 채, "생성된 ID는 1" 테스트 실행 → 두 번째 실행부터 깨지는 걸 관찰

실험 3. @transactional 롤백이 동시성 테스트에서 무력한 것 확인

• @Transactional 붙인 테스트에서 멀티스레드로 데이터를 만들고, 롤백 후에도 데이터가 남는지 확인

이런 실험은 "왜 격리가 필요한가"를 말로 아는 것과, "격리가 깨지면 이렇게 된다"를 눈으로 본 것의 차이를 만들어준다고 생각합니다.

8. 미션에서의 제 선택

이번 예약 대기 미션 기준으로 제가 격리를 다루는 방식입니다.

일반 통합 테스트 (CRUD, 유스케이스 흐름)

• @Transactional 롤백을 기본으로 사용. 빠르고 간결하며 대부분의 검증에 충분합니다.

트랜잭션 경계 검증 (예약 취소 → 대기 승격의 원자성)

• 테스트 @Transactional을 쓰지 않고, 명시적 cleanup으로 처리. 롤백이 트랜잭션 경계를 가려버리면 "중간 실패 시 전체 롤백"을 검증할 수 없기 때문입니다.

동시성 테스트 (동시 대기 신청, 동시 예약)

• 멀티스레드로 동작하므로 @Transactional 롤백이 무력합니다. truncate 기반 cleanup으로 처리합니다.

검증 스타일

• hasSize(전체개수)보다 내가 만든 데이터를 특정해서 검증하는 방식을 선호합니다. 다른 데이터가 섞여도 깨지지 않아 격리에 강합니다.

9. 정리

저는 테스트 데이터 격리를 이렇게 정리할 수 있을 것 같습니다.

격리는 청소의 문제가 아니라, 각 테스트가 자기만의 알려진 출발점을 어떻게 보장받을 것인가의 문제다. 그리고 방법마다 보장 범위와 함정이 다르다.

• @Transactional 롤백: 빠르고 간결하지만, 실제 커밋·트랜잭션 경계·동시성을 검증하지 못한다
• truncate/@SQL 초기화: 운영에 가깝고 동시성에도 동작하지만, 느리고 외래키 순서·AUTO_INCREMENT 함정이 있다
• 명시적 데이터 생성: 자기완결적이고 명확하지만, 전체 개수 의존 검증을 피하고 cleanup과 함께 써야 한다

핵심은 "어느 한 방법이 정답"이 아니라, 검증 대상에 따라 방법을 나누는 것입니다.

단순 검증은 롤백으로 빠르게, 트랜잭션 경계와 동시성은 실제 cleanup으로 — 이렇게 나누는 기준은 결국 이 테스트에서 롤백이 검증 대상을 가려버리는가라고 생각합니다.

그리고 무엇보다, 격리가 깨졌을 때의 증상(순서 의존, 혼자는 통과·전체는 실패)을 한 번 직접 겪어보는 것이 격리를 진짜로 이해하는 가장 빠른 길이라고 봅니다.

[Uechann]

테스트 격리란

테스트 격리

각 테스트가 다른 테스트의 상태에 영향을 주지도, 받지도 않게 만드는 것이다.
핵심은 한 테스트를 단독으로 돌리든, 1000개 중 하나로 돌리든, 순서를 섞어 돌리든 결과가 똑같아야 한다.

• 단독으로 돌리든
• 1000개 중 하나로 돌리든
• 순서를 섞어 돌리든

테스트 격리의 대상은 3가지가 존재한다.

1. DB 같은 영속 상태
2. 싱글톤 빈/static 필드 같은 메모리 상태
3. 시간, 랜덤, 외부 API 같은 환경 상태

왜 테스트 격리가 필요할까?

왜 테스트 격리가 필요할까?

테스트가 격리가 안되어 있다면 생기는 문제점들이 존재한다.

1. 순서 의존 order Dependency

A → B라면 통과하고 , B → A라면 실패하는 상황이라면,
테스트가 순서에 의존을 하게 된다.

2. 누적 오염

예약 생성에 대한 테스트 데이터가 남아있는 상황이라면
다음에 테스트하는 상황에서 조회했을 때 데이터의 개수에 대한 검증, 중복 검증에 대한 부분에서 오염이 발생한다.

3. 유령 통과

어제는 되던 테스트가 오늘 안된다는 상황이 발생하게 된다.
날짜에 대한 의존이 생기거나, 테스트에 대한 신뢰성이 떨어지게 된다.

이렇듯 테스트가 존재한다면 그 테스트가 신뢰할 수 있어야 한다.

어떻게 테스트 격리를 해야할까?

어떻게 테스트 격리를 해야할까?

1. 트랜잭션 롤백 (@transactional on test)

테스트 메서드 전체를 하나의 트랜잭션으로 감싸고,
끝나고 나면 commit 대신에 rollback으로, DB에 실제로 남아있지 않게 한다.

단점:

• 1차 캐시 영속성 컨텍스트 때문에 실제 DB에 안들어간 문제를 잡을 수 없다.
• 세션이 계속 열려 있어서 LazyInitializationException 같은 버그가 숨어버린다.
• 별조 스레드(비동기), REQUIRES_NEW, @Commit 코드들은 롤백의 밖이어서 격리가 되지 않는다.

2. @DirtyContext

테스트 후 ApplicationContext 자체를 버리고 새로 띄운다.
DB 뿐만 아니라 모든 빈 상태가 초기화되기 때문에 격리 측면에서는 확실하다.

단점:

• 컨텍스트 재생성 비용이 커서, 속도가 확실히 느리가.
• DB 격리 용도로 사용한다면 오버킬이다.
• 싱글톤 빈 상태가 오염됐을 때처럼 정말 컨텍스트를 갈아야 할 때만 사용할 수 있다.

3. 테이블 초기화 (truncate / deleteAll)

@beforeeach나 @SQL로 실제 DB를 비운다.

실제 commit이 일어나기 때문에 운영 동작에 가장 가깝고 롤백의 단점을 보완할 수 있다.

단점:

• 롤백보다 속도가 느리다.
• FK 제약 때문에 삭제 순서를 신경 써야한다.
• auto-increnment ID 리셋의 문제가 있다.

4. 고유 데이터 사용하기

테스트마다 충돌이 안나는 키를 써서 애초에 부딪히지 않게 한다.
이렇게하면, 정리를 안해도 되고 병렬 실행에 강력하다.

단점:

• 데이터가 계속 누적되므로 전체 조회 검증시에는 통하지 않는다.
• 그래서 격리보다는 충돌 회피에 가깝다.

상황에 따라 어떻게 테스트 격리를 보장해야할까?

상황에 따라 어떻게 테스트 격리를 보장해야할까?

격리를 해야하는 방법

• 기본적으로 트랜잭션 롤백을 사용한다.
  대부분의 통합 테스트는 이거로 충분하고 빠르다고 생각한다.
• 롤백이 통하지 않을 때 (비동기, 실제 commit 후 동작 검증, 전체 조회 카운트 검증)
  는 테이블 초기화로 전환한다.
• 병렬 테스트를 사용하려면 고유 데이터를 보조로 사용한다.

격리에 주의해야하는 점:

• @DirtiesContext는 DB 격리 목적으로는 거의 사용하지 않는다.
  속도가 느리고, 빈 상태 오염 등 진짜 필요할 때에만 사용한다.
• 고유 데이터만으로 격리됐다고 믿으면 안된다.
  전체 조회, 중복, 검증에서 깨지게 된다.

정리

정리

테스트 격리란
테스트끼리 영향을 서로 안주고 받는 것이다.

테스트끼리 서로 영향을 주고 받게 된다면 위아 같이 같은 문제가 존재하게 된다.

1. 순서 의존
2. 누적 오염
3. 유령 통과

이런 문제점들을 해결하기 위해서 테스트끼리 서로 격리를 하게 되는데,
테스트가 격리가 되었다는 기준을 생각한다면 다음과 같은 질문들을 생각해볼 수 있을거 같다.

• 테스트 실행 순서를 랜덤으로 섞어도 결과가 같은가?
  (@TestMethodOrder (MethodOrderer.Random.class)호 확인 가능
• 하나만 단독 실행해도 통과하는가 ?
• 병렬 실행해도 통과하는가 ?
• 공유 가변 상태에 의존하지 않는가?
• 한 테스트가 다른 테스트가 만든 데이터의 존재를 가정하는가?

이 5개의 질문들을 다 통과 한다면 격리가 되었다고 봐도 좋고,
이렇게 격리가 된다면 더욱 더 신뢰할 수 있는 테스트가 될수 있다고 생각한다.

[sangjun121]

테스트 실행 컨텍스트 격리가 필요한 이유

테스트 격리는 테스트가 서로 영향을 주지 않도록 구성하는 것을 의미합니다. 즉, 어떤 순서로 테스트를 실행하던지 항상 같은 결과가 나오도록 보장하기 위해서는 테스트 격리가 필요합니다.

테스트의 실행 순서가 변경되었을 때, 결과가 변동될 수 있는 가장 보편적인 이유는 테스트 실행이후 데이터의 변화 때문인데, 앞선 테스트의 실행 이후 데이터의 변화에 따라 테스트의 결과가 영향을 받을수 있기 때문입니다.

예를 들어, 회원 생성 API 테스트를 실행하고 회원 조회 API 테스트를 실행할 때, 회원조회 테스트가 현재 존재하는 데이터의 개수로 검증 결과가 판단된다면, 이 테스트는 앞선 생성 테스트 때문에 실패하게 됩니다.

그렇기 때문에 각 테스트는 앞선 컨텍스트에 영향을 받으면 안되며 격리되어 독립적으로 실행되도록 보장해야합니다.

테스트 격리를 위한 도구들

테스트 격리를 위해 사용할 수 있는 방법은 대표적으로. @DirtiesContext , @Transactional, @Sql truncate가 있는데, 각 키워드가 어떻게 컨텍스트 격리를 보장하는지 알아보고, 장단점을 살펴보겠습니다.

1. @DirtiesContext

스프링 컨텍스트를 각 테스트 마다 새로 생성하는 방식입니다. 물론 옵션을 설정하여 메서드 혹은 클래스 단위로 언제 스프링 컨텍스트를 버릴 지 지정할 수 있습니다.

어플리케이션 컨텍스트를 모든 실행단위에서 초기화할 수 있다는 장점이 있지만, 모든 실행 단위 앞에 컨텍스트를 생성해야하기에 시간상의 트레이드 오프가 발생합니다. 그리고 @DirtiesContext는 근본적으로 스프링 컨텍스트를 초기화해주지, DB에 저장된 데이터를 초기화해주지는 않습니다. (앞선 미션에서 @DirtiesContext가 DB를 초기화해줬던 이유는 인메모리 데이터 베이스를 선택했기 때문입니다. 속지맙시다.. 전 속을 뻔했습니다..)

2. @Transcational

가장 보편적으로 사용되는 키워드로, 테스트 클래스나 메서드에 해당 키워드를 붙이면 구현 코드와는 다르게, 기본적으로 테스트 종료시점에 자동으로 롤백됩니다. (저희가 서비스에서 사용하는 @transactional과 다르게 성공한다고 커밋되지 않습니다. 이는 Spring TestContext Framework가 다른 방식으로 처리하기 때문입니다.)

다만, 인수 테스트의 경우에는 스프링 서버가 트랜잭션을 새로 만드는 경우 서로 다른 스레드에서 실행되기 때문에 RestAssured로 실제 서버를 호출해서 생성된 트랜젝션이 커밋한 데이터는 롤백되지 않을 수 있기에 주의해야합니다.

여기서 오해할 수 있는 부분으로 @transactional이 붙은 테스트로, @transactional이 붙은 Service를 통합테스트 한다면, 우회되어 문제가 생길 수 있다고 오해할 수 있다고 생각합니다. 하지만, 서비스의 @transactional은 새 트랜잭션을 만드는 것이 아니라 기본 전파 속성(REQUIRED) 때문에 이미 존재했던 테스트의 트랜젝션에 참여하게 되어 롤백에 문제가 발생하지 않습니다.

3. Truncate로 테이블 초기화 및 원복

@SQL로 테스트 실행 전후에 Truncate SQL 스크립트를 실행하여 데이터베이스 상태를 초기화하는 방법입니다.

앞서 트랜잭션 롤백으로 해결하기 어려운 경우나, 복잡한 초기 데이터 세팅(data.sql)이 필요한 통합 테스트 환경에서 유용하게 활용할 수 있습니다.

Truncate는 테이블 데이터를 통째로 삭제하는 명령어로, @Sql("./data.sql")를 함께 사용한다면 초기 데이터 상태를 유지할 수 있습니다.

단점은, 테이블이 추가될때마다 TUNCATE 메서드를 추가해줘야 하며, FK로 테이블간의 연관관계가 매핑되어 있는 경우, 자식 테이블을 먼저 지우고, 부모 테이블을 지워줘야 하는 등 번거로운 작업이 수반됩니다. 그렇기 때문에 트랜잭션 롤백이 통하지 않는 통합테스트에서 사용하기 유리합니다.