@Transactional을 테스트에 써야할까?

Don’t Use @Transactional in Tests

예전에 이 글 보고 쓰지말자라고만 생각했다.

@Transactional을 써서 얻는 부작용이 꽤 많아 보였기 때문이다.

위 영상을 보면 @Transactional을 테스트에 쓰는 것이 단점에 비하면 얻는 장점이 많다고 한다.

영상에 나온 단점을 다 이해할 순 없지만 개인적으로 느꼈던 단점 중 하나는 트랜잭션이 비즈니스 로직에 적혀있지 않아도 테스트에 있는 @Transacitonal이 전파된다라는 특징 때문에 운영 서비스에 크리티컬 이슈를 발생시킬 수도 있다라는 생각을 했다.

영상에선 그 외 단점도 설명도 하고 있는데 JPA를 이용했을때 트랜잭션 테스트를 하고 싶으면 Flush를 명시적으로 사용해야한다고 한다.(사실 생각도 안해본 부분)
@Transactional을 테스트에 사용했을때 롤백으로 끝나는 테스트는 정작 DB까지 날아가지 않고 Flush가 되지 않는다고 한다. 그래서 DB에 잘 들어가는지 확인이 안되기 때문에 Flush를 명시적으로 사용해야한다고 한다.

그 외에도 Self-Invocation에 대해서도 얘기하고 계신데 이 부분은 단점인지는 잘 모르겠다.

 

그래서 원래는 @Transactional을 쓰지 말자라는 주의였는데, 저명하신 두분(토비+영한님)이 쓰자는 데 동의하시기 때문에 나도 그 생각에 휙 올라타기로 했다. 그 이유는 몇개가 있었는데 생각나는건 첫번째로 테스트코드 작성속도 빠르다라는 점이고 두번쨰는 DB용 단위테스트(보기에 따라 통테)가 쉽다는 것이었다.

 

여튼 나도 @Transactional을 안쓴다라는 마인드였는데 그런 생각에 대해 토비님이 마지막에 "그럼 DB 테스트는 어떻게 할건가요?"라는 얘기에서 나의 답변은 "통합테스트는 느리기도 하고 짤 생각이 딱히 없었다"였다.

단위 테스트는 기본적으로 기능이 잘 된다라는 가정하에 돌아간다고 생각해서 통합테스트를 안한다라는 생각을 했다.

하지만 영상에서는 테스트코드는 애플리케이션 코드를 완벽하게 검증할 수 없기에 실제 환경 테스트는 인수테스트를 해야하는거라고 말하고 있으며 완벽하지 않기 때문에 @Transactional을 사용하면서 단점을 정확히 인지하고 코드리뷰로 서로 검증하면서 테스트코드를 작성하는 것이 좋다라고 설명해주셨다.

 

재작년인가 작년쯤에 고민했던 부분을 大선배님들이 어떻게 생각하시는지에 대한 인사이트를 얻을 수 있어서 좋은 영상이었다.