Fixture 클렌징 관련 질문드립니다.

Practical Testing: 실용적인 테스트 가이드

Test Fixture 클렌징

해결된 질문

작성

201

수정됨

안녕하세요! 저는 강사님이 말씀해주신 방법들이 아닌 @Sql 어노테이션을 사용해서 모든 테이블을 Truncate하는 방법으로 클렌징을 하고 있었습니다.

Truncate는 복구가 안되지만 성능 면에서 Delete보다 빠른 것으로 알고 있는데 제가 사용한 방식도 괜찮은 방법일지, 혹은 발생할만한 문제가 있을지 궁금합니다.

teardown.sql

-- 모든 제약 조건 비활성화
SET REFERENTIAL_INTEGRITY FALSE;

truncate table user_tb;
truncate table oauth_tb;
truncate table vote_tb;
truncate table choice_tb;
truncate table vote_item_tb;
truncate table place_tb;
truncate table review_tb;
truncate table review_vibe_tb;
truncate table vibe_tb;
truncate table place_vibe_tb;
truncate table place_food_tb;
truncate table food_tb;
truncate table participant_tb;

-- 모든 제약 조건 활성화
SET REFERENTIAL_INTEGRITY TRUE;

spring tdd jpa mockito 소프트웨어-테스트 junit5

답변 2

박우빈

지식공유자

안녕하세요, 이승민 님!

말씀주신 방법도 좋은 접근 중 하나일 수 있겠네요. ㅎㅎ
다만 테이블이 추가/삭제/변경되는 경우 해당 파일을 지속적으로 관리해줘야 한다는 점 정도가 관리 포인트가 되겠네요.

감사합니다. 🙂

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다.

이승민님, 테스트 후 데이터베이스 상태를 초기화하는 방법으로 @Sql 어노테이션을 사용하여 테이블을 TRUNCATE하는 것은 테스트 간 격리(isolation)를 확보하기 위한 하나의 접근 방법입니다.

TRUNCATE를 사용하는 것은 DELETE에 비해 성능상 이점이 있으며, 특히 대용량 데이터를 다루는 테이블에서 더욱 그 차이가 두드러질 수 있습니다. 하지만, TRUNCATE가 더 빠른 이유 중 하나는 트랜잭션 로그를 남기지 않고 실행되기 때문에 복구가 불가능합니다. 그러므로 테스트 환경에서 사용하는 것은 일반적으로 문제가 되지 않지만, 실제 운영 환경에서는 주의가 필요합니다.

모든 제약 조건을 비활성화하고 TRUNCATE를 실행할 때는 외래 키 제약 조건 등에 대한 의존성이 제거되므로, 테스트에 영향을 주지 않도록 조심스럽게 처리해야 합니다. 외래 키 제약 조건이 다시 활성화될 때 해당 제약 조건을 만족하는지 점검이 필요할 수 있습니다.

@Sql 어노테이션을 사용해 지정한 SQL 스크립트는 테스트 실행 전후에 실행되므로, 이 방법을 사용하면 테스트 메소드나 클래스 수준에서 쉽게 데이터베이스를 초기화할 수 있습니다. 이 방식이 이승민님의 테스트 환경과 요구 사항에 적합하고, 특별히 문제가 발생하지 않았다면 계속 사용하셔도 무방합니다.

그러나 모든 상황에서 TRUNCATE가 완벽한 해결책이라고 할 수는 없으므로, 테스트 케이스의 복잡성이나 데이터베이스의 특성에 따라 적절한 방법을 선택하는 것이 중요합니다. 예를 들어, ID 생성 전략이나 캐시와 같은 데이터베이스의 특정 동작에 영향을 받는 경우, TRUNCATE 후의 상태가 테스트에 영향을 줄 수 있으니 주의하셔야 합니다.

인프런 커뮤니티 질문&답변

Fixture 클렌징 관련 질문드립니다.