인프런 커뮤니티 질문&답변
작성한 질문수
검증 필드의 영역
작성
·
49
·
수정됨
0
안녕하세요 사이드 프로젝트를 하면서
선생님에게 배운 테스트를 적용하며 성장 하고 있습니다.
감사합니다! 👍
테스트를 하며 작은 궁금증이 생겼습니다.
만약 10개의 필드를 업데이트 한다면 모든 필드를
extracting 하여 검증 해야 하나요?
3~4개의 대표적인 필드만 하는게 맞을까요?
다 검증 하는게 안정성은 무조건 좋다고 생각 합니다.
하지만 검증 부분이 길어 가독성이 좋지 않을것 같기도 하고
3~4개면 검증 되지 않을까 하는 생각도 듭니다.
다른 질문은 프로젝트 중 고민이 있어서 혹시 선생님은
어떻게 생각 하시나 궁금해서 여쭈어 봅니다. 🙏
현재 프로젝트에서
요청 할때 JWT 토큰을 내고 user의 정보를
시큐리티 컨텍스트 홀더에 저장 하고 있습니다.
api 요청이 올 떄
@GetMapping("/{id}")이렇게 파라미터로 받지 않고
컨텍스트 홀더의 유저 ID를 사용 하고 있습니다.
컨텍스트 정보를 UserUtils로 만들고 서비스에서
utils 값을 꺼내어 사용 하고 있습니다.
현재 까진 문제가 없는데 혹시 안좋은 방법인가요?
마지막 질문은 블로그에 테스트에 관해 작성 해도 괜찮을까요?
테스트의 전체적인 흐름을 알려주는 곳이 없어서 답답했는데
컨트롤러, 서비스, 리포지토리 각 어떤것을 중점으로 테스트 하는지 적을려고 합니다.
선생님 코드가 일부 인용 할 것 같아서 혹시 가능할까요?
물론 출처는 남길거에요!
답변 2
1
안녕하세요, 조희제 님!
만약 10개의 필드를 업데이트 한다면 모든 필드를
extracting 하여 검증 해야 하나요?
3~4개의 대표적인 필드만 하는게 맞을까요?
말씀하신 것처럼 안정성 측면에서는 다 검증하는 것이 물론 좋으나, 전체적인 비용을 고려했을 때 검증에 충분하다고 생각하는 정도만 해도 괜찮다고 생각합니다.
컨텍스트 정보를 UserUtils로 만들고 서비스에서
utils 값을 꺼내어 사용 하고 있습니다.
가능한 방법입니다만, 동시성 문제가 없게 구현과 테스팅은 충분히 이루어져야 할 것 같아요.
잘못해서 User ID가 꼬여버리기라도 하면 큰 문제가 생길 수도 있겠죠.
그리고 Utils 라는 이름은 보통 도메인과 관련 없는 범용적인 헬퍼 메서드들을 모아놓는 클래스에 어울리기 때문에(ex. StringUtils, LocalDateTimeUtils), 다른 이름이 좀 더 좋지 않을까 합니다.
마지막 질문은 블로그에 테스트에 관해 작성 해도 괜찮을까요?
강의 예제와 내용을 그대로 옮기는 수준이 아니라 요약하는 정도라면 괜찮습니다.
감사합니다. 🙂
0
안녕하세요, 인프런 AI 인턴입니다.
조희제님께서 여러 가지 질문을 주셨는데요, 하나씩 답변 드리겠습니다.
모든 필드를 검증해야 하나요?
- 모든 필드를 검증하는 것은 안정성을 높이는 측면에서 분명히 이점이 있습니다. 하지만 매번 모든 필드를 검증하는 것은 테스트 코드의 가독성을 떨어트리고 유지보수를 어렵게 만들 수 있습니다. 일반적으로 필드 중 핵심적인 부분, 즉 애플리케이션의 주요 로직에 영향을 미치는 3~4개의 필드를 주로 검증하는 것이 현실적입니다. 이렇게 함으로써 적절한 수준의 안정성과 효율성을 확보할 수 있습니다.
- 모든 필드를 검증하는 것은 안정성을 높이는 측면에서 분명히 이점이 있습니다. 하지만 매번 모든 필드를 검증하는 것은 테스트 코드의 가독성을 떨어트리고 유지보수를 어렵게 만들 수 있습니다. 일반적으로 필드 중 핵심적인 부분, 즉 애플리케이션의 주요 로직에 영향을 미치는 3~4개의 필드를 주로 검증하는 것이 현실적입니다. 이렇게 함으로써 적절한 수준의 안정성과 효율성을 확보할 수 있습니다.
JWT 토큰을 사용하여 시큐리티 컨텍스트 홀더에 정보 저장하는 방식
- 현재 구현한 방식은 보편적으로 많이 사용하는 방법 중 하나입니다. 시큐리티 컨텍스트 홀더를 통해 인증된 유저의 정보를 사용하게 되면, API 경로에 불필요한 정보를 줄일 수 있어 간결한 API 설계를 할 수 있습니다. 그러나 이 방식은 동시성이 높은 상황이나 정보의 무결성이 매우 중요할 때는 주의하여 사용해야 할 수도 있습니다. 성능이나 보안 면에서 문제가 생긴다면, 로깅 및 세션 관리를 강화하는 방식을 고려해볼 수 있습니다.
- 현재 구현한 방식은 보편적으로 많이 사용하는 방법 중 하나입니다. 시큐리티 컨텍스트 홀더를 통해 인증된 유저의 정보를 사용하게 되면, API 경로에 불필요한 정보를 줄일 수 있어 간결한 API 설계를 할 수 있습니다. 그러나 이 방식은 동시성이 높은 상황이나 정보의 무결성이 매우 중요할 때는 주의하여 사용해야 할 수도 있습니다. 성능이나 보안 면에서 문제가 생긴다면, 로깅 및 세션 관리를 강화하는 방식을 고려해볼 수 있습니다.
블로그에 테스트 내용 작성 관련
- 블로그에 테스트에 관한 내용을 작성하시는 것은 많은 분들에게 유익할 것 같습니다. 선생님의 코드를 인용하실 때 출처를 명확히 밝히신다면 보통 큰 문제가 되지 않을 겁니다. 컨트롤러, 서비스, 리포지토리 별로 무엇을 중점적으로 테스트할지에 대한 내용은 많은 초심자와 중급자에게 큰 도움이 되겠지요.
- 블로그에 테스트에 관한 내용을 작성하시는 것은 많은 분들에게 유익할 것 같습니다. 선생님의 코드를 인용하실 때 출처를 명확히 밝히신다면 보통 큰 문제가 되지 않을 겁니다. 컨트롤러, 서비스, 리포지토리 별로 무엇을 중점적으로 테스트할지에 대한 내용은 많은 초심자와 중급자에게 큰 도움이 되겠지요.
추가적으로 Spring Boot의 테스트에 대한 자세한 정보는 Spring Boot Reference Documentation 테스트 섹션에서 확인할 수 있습니다.
궁금증이 해결되셨길 바랍니다! 더 많은 질문이 있으시면 언제든지 말씀해주세요. 😊