제가 테스트 강의를 다 보고 프로젝트를 진행하던 도중에 막혔던 테스트 케이스가 있어 이렇게 문의드립니다. 바쁘시겠지만 혹시나 시간이 나신다면 한번 피드백 주시면 감사하겠습니다 ㅠㅠ
간단하게 궁금한점을 작성해봤습니다.
- 블로그에 작성한 것처럼 외부로 분리해서 테스트한게 맞았을까요??
- @WithMockUser에 대해 제가 정확하게 이해한게 맞을까요??
- 틀리거나 부족한 내용은 없을까요??
좋은 하루보내세요
감사합니다.
제가 테스트 강의를 다 보고 프로젝트를 진행하던 도중에 막혔던 테스트 케이스가 있어 이렇게 문의드립니다. 바쁘시겠지만 혹시나 시간이 나신다면 한번 피드백 주시면 감사하겠습니다 ㅠㅠ
간단하게 궁금한점을 작성해봤습니다.
- 블로그에 작성한 것처럼 외부로 분리해서 테스트한게 맞았을까요??
- @WithMockUser에 대해 제가 정확하게 이해한게 맞을까요??
- 틀리거나 부족한 내용은 없을까요??
좋은 하루보내세요
감사합니다.
안녕하세요, HOYA 님! :)
블로그에 작성해주신 내용 잘 읽었습니다.
문제 상황을 보니 Auto Increment 되는 ID 값을 검증하고자 했으나, 여러 테스트의 수행에 따라 예측하기 어려운 값이 되어서 고민이셨던 것 같은데요.
일단 Auto Increment 되는 ID 값은 말 그대로 단조증가하는 값이기 때문에, 데이터가 롤백된다고 해서 해당 값도 되돌아가지는 않습니다.
그래서 DB에서 부여한 해당 ID 값이 중요하지 않다면 굳이 검증하지 않는 방법도 있고요.
만약 ID의 검증이 중요한 상황이라면, given절에서 정확한 ID값은 모르더라도 ID 값을 조회할 수 있도록 테스트 코드를 구성하는 것이 필요합니다.
위와 같이 repository를 통해 저장한 뒤 받은 반환 Entity User는 DB로부터 ID를 받은 상태일 것입니다.
savedUser.getId()를 해서 ID 값을 가져온다면, 해당 값이 실제로 1인지 2인지는 알기 어렵지만 검증에는 내가 원하는 그 값이 맞는지 비교하는 용도로 사용해볼 수 있습니다.
테스트를 위해 userId를 분리한 시도는 좋습니다만, 서비스 외부 계층에서 userId를 알아야 하는 어색함이 있을 수 있을 것 같아요.
전체 프로덕션 코드를 다 확인해본 것은 아니지만, 적용해주신 securityService mocking 으로도 충분히 해결할 수 있지 않을까 합니다. :)
도움이 되셨기를 바랍니다.
감사합니다. :)
답글
HOYA
2023.11.06아하 그냥 외부로 분리하지 않고 서비스단에서 mocking을 하는게 더 자연스럽게 보일 것 같네요 !! 답변 감사합니다 :)