스프링에 대해서 여러가지 공부를 하던중, 정리 해놓으면 좋을 것 같은 주제를 정리하려고 한다.
이번에 다룰 주제는 테스트에서의 @Transactional 사용이다.

평소에도 테스트 코드를 작성하며 @Transactional 사용에 대해서 생각을 가지고 있었지만, 이렇게 글으로 다룰 생각은 하지않았다. 왜냐하면 너무나 당연하게 사용하였고, 내가 더 주의해서 사용하면 된다는 생각이었기 때문이다. 하지만 테스트에서의 @Transactional 사용에 대해 질문이 있습니다.을 발견하였고, 해당 글에 내용이 흥미로워서 자료들을 더 찾아본 결과 생각보다 많은 개발자들이 해당 내용에 대해서 의견이 다른 것을 알게 되었다. 그래서 해당 내용을 정리해보고 현재 시점에서의 나의 생각을 기록해보려고 한다.

1. 어떤 문제가 발생할까?

테스트 데이터 초기화에 @Transactional 사용하는 것에 대한 생각
해당 게시글에 "향로"님이 자세히 정리 해주셨기 때문에, 간단히 기록만 해두고 넘어가겠다.

1-1. 의도치 않은 트랜잭션 적용

• 실제 코드에서는 @Transacational 이 누락되어있으며
• 테스트 코드에서는 데이터 초기화를 위해 @Transacational 이 포함되어있다.

하지만 해당 내용에 대해서는 Service에서는 @Transacational(readOnly=true) 를 기본적으로 선언해서 거의 문제가 발생하지 않을 것이다.

1-2. 트랜잭션 전파 속성을 조절한 테스트 롤백 실패

• 테스트 클래스에 @Transactional 로 선언하면 트랜잭션 전파 레벨에 따라 데이터 초기화가 작동되지 않는다는 것이다.
• 이는 해당 테스트가 끝나고 초기화 되지 않는 데이터로 인해 다른 테스트가 영향을 받을 수 있다는 것을 의미한다.

1-3 비동기 메서드 테스트 롤백 실패

• 비동기 메소드에서도 역시 해당 테스트가 끝나고 초기화 되지 않는 데이터로 인해 다른 테스트가 영향을 받게 되어 각 테스트간 격리가 될 수 없다.

1-4 TransactionalEventListener 동작 실패

• TransactionPhase.AFTER_COMMIT라고 설정한다면, 트랜잭션 커밋이 성공한 이후 시점에 실행된다. 하지만 테스트의 트랜잭션 커밋이 끝나지 않았기 때문에 TransactionalEventListener 가 수행될 수가 없다.

2. 생각정리

여러가지 문제점들을 정리해보았다. 흠.. 그래서 테스트에서의 @Transactional 사용을 하면 안될까에 대한 내 생각을 정리하자면, 나는 @Transactional에 대해서 사용할 것 같다. 위에서 실컷 문제에 대해서 정리해놓고 이런 의견을 말하면 좀 이상하긴하다. 하지만 내가 사용해도 된다고 생각 하는 것에는 아래의 내용 때문이다.

• 테스트 코드 작성 속도가 빠르기 때문에 테스트를 더 적극적으로 활용할 가능성도 높아진다.
• @Transactional 테스트에서 제대로 검증이 되지 않는 문제를 잘 인식하고 작성을 해야 한다.
• 테스트를 웬만큼 잘 작성해도 애플리케이션 코드를 완벽하게 검증할 수는 없다는 사실을 인식해야 한다.

지금까지 다루었던 내용들에 대해서 간단하게 정리하자면 아래와 같다.

" @Transactional 롤백 테스트 쓰는 대신에 커밋시키고 tearDown을 사용한다면 실용성이 너무 떨어지잖아요. 몇가지 조심하면 되는데 그것 때문에 오만가지 불편함을 감수하면서 초가삼간 다 태울 수 없으니..."

이번 게시글에 대해서는 테스트에서의 @Transactional 사용에 대해서 정리 해보았다. 해당 내용에 대해서는 뛰어난 개발자들도 의견이 갈리는 만큼, 정답은 없는 것 같다.
하지만 현재 시점에서의 내 생각은 @Transactional 테스트에서 발생하는 문제에 대해서 제대로 이해하고 테스트 코드를 작성하는 것이 맞다고 생각한다.