안녕하세요 :)평소 영한님 강의를 통해 많은 가르침을 받고 있는 주니어 개발자입니다.만약 별도 Test DB 없이 Service 계층 테스트를 한다면,크게 다음과 같은 세가지 테스트 방식이 있는 것으로 이해하였습니다!Service 테스트에 @Transactional 추가하여, 테스트 수행 후 롤백실제 DB에 수행하므로, insert시 유니크한 컬럼에 대해 이미 동일 데이터가 존재한다면 테스트 실패Repository 의존성을 Mock 처리Mock을 통해 행위를 검증하게되므로 보다 깨지기 쉬운 테스트가됨임베디드 DB에 테스트 수행임베디드 DB와 운영환경 DB의 차이점이 있을 수 있음세가지 방식 모두 각자의 트레이드오프가 있을 것 같은데요.권장되는 방식이나, 주로 사용하시는 테스트 방식이 궁금합니다.

우선 해야하는 테스트 방식이 궁금합니다.

23.03.12 16:56 작성 조회수 393

안녕하세요 :)
평소 영한님 강의를 통해 많은 가르침을 받고 있는 주니어 개발자입니다.

만약 별도 Test DB 없이 Service 계층 테스트를 한다면,
크게 다음과 같은 세가지 테스트 방식이 있는 것으로 이해하였습니다!

Service 테스트에 @Transactional 추가하여, 테스트 수행 후 롤백
- 실제 DB에 수행하므로, insert시 유니크한 컬럼에 대해 이미 동일 데이터가 존재한다면 테스트 실패
Repository 의존성을 Mock 처리
- Mock을 통해 행위를 검증하게되므로 보다 깨지기 쉬운 테스트가됨
임베디드 DB에 테스트 수행
- 임베디드 DB와 운영환경 DB의 차이점이 있을 수 있음

세가지 방식 모두 각자의 트레이드오프가 있을 것 같은데요.
권장되는 방식이나, 주로 사용하시는 테스트 방식이 궁금합니다.

스프링 DB 2편 - 데이터 접근 활용 기술

테스트 - 임베디드 모드 DB

강의실 바로가기

답변 1

답변을 작성해보세요.

y2gcoder

2023.03.12

안녕하세요, 가즈아 님. 공식 서포터즈 y2gcoder 입니다.

말씀하신대로 각자의 테스트가 정답이 없고, 프로젝트 상황에 따라 달라질 수 있다고 생각합니다.

이에 대해서 스스로 고민해볼 수 있는 글이 있어 추천드리겠습니다.

감사합니다.

가즈아

2023.03.12

답변과 링크 공유 감사드립니다 :)

제가 생각하기로는 운영 DB에 영향 주지 않으면서,
Mocking 없이 테스트가 가능한,
3안의 임베디드 DB 방안이 가장 나아보이긴 하는데요..!
제가 경험한 실무에서는, 임베디드 DB 를 사용해 테스트하는 경우가 많지 않더라구요ㅜ

아직 대중화가 안된건지,
아니면 임베디드 DB 를 실무에서 지양해야하는 별도의 이유가 있는건지 궁금합니다.

y2gcoder

2023.03.12

저도 경험이 많지 않아 조심스럽습니다만,

아무래도 질문글에서 말씀해주신 것과 같이 실제 운영 DB와 임베디드 DB 사이의 차이가 가장 큰 이유가 아닌가 싶습니다.

그래서 여건이 되는 곳에서는

로컬, 개발 서버, 스테이징 서버, 운영 서버로 개발 단계를 나누고

스테이징 서버에서는 실제 운영 서버와 동일한 환경을 만들어 테스트를 진행한다고 합니다. 아마도 그 단계에서 실제 DB와 동일한 환경의 테스트 환경을 만들어 테스트하는 과정도 진행되지 않을까 추측합니다.

가즈아

2023.03.13

아하 운영 DB가 아닌 다른 환경 DB에 테스트를 수행하면, 굳이 임베디드 DB를 띄울 필요가 없겠군요
운영에 영향을 안주다보니, 테스트 수행전 겹치는 데이터를 제거해도 무방할 것 같고요.

답변 주셔서 감사합니다 :)

y2gcoder

2023.03.14

감사합니다:)

파이팅입니다!