테스트 격리 방법과 차이

[GIVEN53]

• @DirtyContext
• @Sql truncate
• @Transactional

번외
Extension

[jimi567]

@DirtyContext

• 목적 : 테스트를 실행 후 애플리케이션 컨텍스트를 다시 로드하도록 하는 테스트 격리 방법 입니다.
• 특징 : 통합 테스트에서 각 테스트가 애플리케이션 컨텍스트를 변경하는 경우, 그 변경 사항이 다른 테스트에 영향을 미치지 않도록 하기 위해 사용 됩니다. 주로, 클래스 레벨, 메소드 레벨에서 격리할 수 있습니다. 각 테스트마다 컨텍스트를 다시 실행하기 때문에 테스트에 소요되는 시간이 매우 긴 편입니다.

@SQL truncate

• 목적 : @SQL은 특정 Sql 쿼리가 테스트 실행 전이나 후에 실행되도록 하기 위해 사용되는 어노테이션입니다. 해당 어노테이션을 활용해 매 테스트 마다 테스트용 데이터를 초기화하거나, 테이블을 정리하기 위해 사용합니다.
• 특징 : 클래스, 메소드 레벨에서 사용가능하며, executionPhase 속성을 통해 사용되는 스크립트의 실행 시점을 지정할 수 있습니다.

@transactional

• 목적 : 테스트 메소드 내에서 트랜잭션을 시작하고, 테스트가 끝나면 롤백하도록 하여 테스트 격리를 가능하도록 하기 위해 사용합니다.

• 특징 : 테스트코드에서의 트랜잭션은 프로덕션과 달리 테스트가 끝나면 롤백되므로, DB 데이터를 테스트 전 상태로 되돌리는데에 유용합니다.
  하지만, 프로덕션 코드에서 트랜잭션이 적용되지 않아서 JPA 변경 감지 등이 제대로 동작하지 않아도 테스트에서는 트랜잭션을 활용해 테스트하게 된다면, 예상과 달리 테스트가 성공하는 경우가 있어서 주의해야 합니다.

번외 @ExtendWith

• 목적 : Junit5에서 커스텀 확장을 사용하기 위해 사용되는 어노테이션입니다.

해당 어노테이션을 활용해, 임의로 만들어둔 DB 초기화 및 테스트 별로 격리되어야 하는 부분을 구현한 클래스를 확장하여 사용함으로서 테스트 격리를 할 수 있습니다.

개인적으로 DirtyContext를 사용하는 것이 가장 확실한 테스트 격리 방법이지만, 실행 시간이 극단적으로 길어져서 , 다른 방식의 테스트 격리 방법을 활용했던 경험이 있습니다.

[GIVEN53]

@DirtyContext

테스트마다 별도의 컨텍스트를 다시 로드합니다. 테스트 간의 컨텍스트 공유를 피하고, 각각의 테스트가 독립적인 컨텍스트에서 실행되는 것을 보장합니다.

단점

• 컨텍스트를 새로 로드하는 것은 비용이 크고 시간이 오래 걸립니다.

@Sql truncate

@Sql은 테스트 실행 전∙후에 특정 SQL 스크립트를 실행할 수 있도록 합니다. 이 때 truncate DDL을 실행하여 테이블 자체를 비움으로써 테스트간 독립된 테이블을 사용할 수 있습니다.

단점

• 테이블이 추가될 때마다 SQL 스크립트를 수정해야 하는 유지보수 비용이 발생합니다.

@Transactional

테스트 메서드를 트랜잭션 내에서 실행되도록 합니다. 테스트 실행 후 트랜잭션을 롤백하여 데이터베이스 상태를 원래대로 유지할 수 있습니다.

단점

• 의도치 않은 트랜잭션 적용으로 프로덕션 환경에서는 실패할 로직이 테스트에서는 성공하는 거짓 음성이 나타날 수 있습니다. (ex. OSIV를 끄고 프로덕션 코드에서는 @Transactional을 사용하지 않았을 때 테스트에서 LazyInitializationException이 발생하지 않음)
• RestAssured를 사용한 인수 테스트는 @SpringBootTest의 WebEnvironment를 DEFINE_PORT 또는 RANDOM_PORT를 사용해서 서버를 띄웁니다 이 때 테스트와 별개의 스레드에서 실행되기 때문에 트랜잭션 롤백이 불가능하게 됩니다.
  reference: https://docs.spring.io/spring-boot/docs/1.5.3.RELEASE/reference/html/boot-features-testing.html#boot-features-testing-spring-boot-applications
• 트랜잭션 전파 레벨을 REQUIRES_NEW로 설정했을 경우 새로운 트랜잭션을 생성하기 떄문에 테스트 트랜잭션과 무관하여 롤백되지 않습니다.
• 비동기 메서드는 롤백되지 않습니다.

거짓 양성(False Positive): 프로덕션 코드는 정상 동작하지만 테스트는 실패
거짓 음성(False Negative): 프로덕션 코드는 실패하지만 테스트는 통과

결론

단점을 염두에 두고 상황에 맞게 선택할 필요가 있고, 팀의 구성원들이 실수하지 않도록 그라운드 룰을 정하는 것도 좋은 방안이 될 수 있습니다.

개인 의견 - @Transactional은 지양하자 + db cleaner extension 구현해서 쓰는게 위 세가지 방법의 단점도 모두 해결되고 가장 깔끔하다고 생각