테스트 코드 작성중 데이터 삭제 방식 결정: delete VS truncate

상황

펀딩 생성 테스트 코드 작성 중 메서드별 데이터의 독립적인 환경을 보장하기 위해 삭제 로직을 추가했습니다.
삭제 방식은 @Sql을 통해 쿼리문을 직접 실행시키는 방법을 선택했습니다.
삭제 해야할 데이터는 funding, anniversary_category, consumer, product_option, product 테이블에 있는 정보들 입니다.
테이블별 1~2개 정도의 레코드를 삭제해야하고, 현재 외래키 제약 조건이 테이블간 걸려 있습니다.
 

고민

쿼리문 작성 과정에서 delete를 사용할지 truncate를 사용할지 고민했습니다.

delete 장점

1. 외래키 제약 조건을 풀고, 다시 잠그는 과정이 필요하지 않음.

delete 단점

1. 삭제시 로그를 남기고, 하나의 데이터씩 삭제하기 때문에 한번에 전체를 삭제하고 로그를 남기지 않는 truncate에 비해 느림.
2. auto_increment 설정된 기본키의 경우 초기화가 안됨.
 

truncate 장점

1. delete와 비교하여 빠름
2. auto_increment 설정되 있는 경우에도 기본키가 초기화되어 처음부터 다시 시작함.

truncate 단점

1. 외래키 제약이 걸린 테이블의 경우, 테이블 레코드 초기화전에 설정이 필요함.
 

해결

delete로 결정했습니다. 이유는 세가지가 있습니다.
1. 현재 메서드별 삭제해야 하는 데이터가 많지 않습니다.
2. 테이블간 외래키 설정이 있기 때문에 truncate의 경우 외래키 제약 조건 설정이 필수적입니다.
3. 테스트시 id값을 직접 넣어주고 있고, 메서드별로 데이터가 삭제되기 때문에 auto_increment에 신경쓰지 않아도 됩니다.
 
하지만 delete시에도 외래키 제약 조건을 설정해야 하는 상황이 생기거나 데이터가 조금이라도 많은 경우가 생긴다면 truncate로 변경할 예정입니다.
 
이유는 (truncate + 외래키 제약 조건 설정)과 (delete + 외래키 제약 조건 설정X)의 속도차이는 얼마 나지 않지만, (truncate + 외래키 제약 조건 설정)과 (delete + 외래키 제약 조건 설정)의 속도차이는 꽤 납니다.
속도 비교와 sql문은 아래 내용을 참고 바랍니다.

 

속도 비교

속도의 경우 테스트마다 차이가 있기 때문에 평균적으로 나오는 속도로 캡쳐했습니다.

delete + 외래키 제약 조건 설정 X

delete from funding where 1;
delete from anniversary_category where 1;
delete from consumer where 1;
delete from product_option where 1;
delete from product where 1;

delete + 외래키 제약 조건 설정 O

SET FOREIGN_KEY_CHECKS = 0;

delete from funding where 1;
delete from anniversary_category where 1;
delete from consumer where 1;
delete from product_option where 1;
delete from product where 1;

SET FOREIGN_KEY_CHECKS = 1;

 

truncate + 외래키 제약 조건 설정 O

SET FOREIGN_KEY_CHECKS = 0;

TRUNCATE TABLE funding;
TRUNCATE TABLE anniversary_category;
TRUNCATE TABLE consumer;
TRUNCATE TABLE product_option;
TRUNCATE TABLE product;

SET FOREIGN_KEY_CHECKS = 1;