Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Member Service 테스트 #646
Member Service 테스트 #646
Changes from 5 commits
a11251c
fc5c0e3
64bd210
4b5f709
7efa1aa
ff58006
88b6344
f23bf30
0565898
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
이 부분인가요??
저는 예외 발생이 해당 메서드의 명세가 되는가 / 그렇지 않은가 에 따라 달라질 것이라 생각해요.
이 부분은 "저장되지 않은 멤버의 정보를 조회하면 예외가 발생한다" 라는 명세를 테스트 하는 것으로 느껴지네요.
테스트가 있는 것이 자연스럽게 느껴집니다!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
네 해당 부분은 서비스 단에서는 예외처리 로직이 존재하지 않고, 레포지토리 단에 예외 로직이 있어요 !
그래서 추가할까 고민했었습니다 !
짱수 의견 말해줘서 고마워요 ~ 저도 동의합니다 !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
저도 짱수 의견에 동의합니다.
테스트 코드는 문서화와 같다고 생각해요. 해당 메서드를 실행했을 때 어떤 오류들이 발생할 수 있는지를 나타내는 것 또한 문서화의 일종이기 때문에 해당 테스트 코드가 전혀 어색하지 않다고 생각합니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
저도요~
모두와 동일하게 생각해요~
[고민]
그래서 테스트를 작성하고 리뷰를 작성하다가 의문이 드는 게 있어요.
테스트에 대한 이야기는 아니지만,,, 테스트를 보다가 생긴 의문이라 공유할게요~
바로 이전
회원가입,
아이디 중복 검사
테스트에서 아이디 길이나, 비밀번호 길이와 같은 부분은 검증되어 있지 않아요.(다른 도메인의 서비스에서도 마찬가지)아마 Controller에서 검증을 하고 있기 때문에 작성되어 있지 않는 것 같아요.
그런데 읽다보니 어색하더라구요~
저는 아이디 길이나, 비밀번호 길이이도 우리 애플리케이션 고유의 요구사항이 비즈니스 로직이라고 생각해요.
따라서 우리 서비스에서 검증이 필요하다고 생각해요.
(그렇다고 null 체크도 검사하자는 것은 아닙니다. null 체크는 어떤 애플리케이션이든 필요하고 우리 서비스만의 규칙이 아님. 근데 아이디 길이를 8~20자로 제한한다든지, 비밀번호에 특수문자를 꼭 넣어야 한다든지 하는 건 우리 서비스만의 특별한 규칙이라고 생각)
여러분들의 의견이 궁금한 것이 있어요. (의견이 많이 갈릴 것 같은데 쓰읍)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jminkkk
오, 저도 비슷한 생각을 헀다가 놓쳤네요.
저도 동일하게 도메인 규칙이고, 비즈니스 로직이라 생각해요.
Service 부분에서의 검증이 진행되는 것이 이상적이며, 우리 서비스에서도 동일하게 적용할 수 있다고 생각합니다.
+)
저는 Controller 의 검증 (즉, DTO 가 스스로 검증) 과 도메인에서의 검증 중 하나만 선택하라면 후자를 선택할 것 같아요.
도메인 검증은 추가하는 것이 좋겠네요
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jminkkk
@zangsu
저는 조금 다르게 생각하는 부분이 있어요.
Service 계층에서 도메인 검증을 테스트할 필요 없다고 생각해요.
도메인 객체의 검증 로직은 도메인의 테스트 코드를 만들어서 테스트해야 하지 않을까요?
DTO에 검증 로직이 들어갔다면 DTO 테스트 코드를 만들어야 한다고 생각해요.
그렇게 하면 서비스 테스트의 부담이 줄어들 것 같네요.
결론은 도메인 테스트와 DTO 테스트를 추가해야 한다 입니다~!
다른 의견 있다면 얼마든지 부탁해용
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
모두 맞는말이라 어렵네요 ~
이런 모든 고민은 'Service 단에서 어디까지 테스트할 것인가'의 고민인 것 같네요.
레포지토리 예외처리도 처리한다, 하위 서비스 예외처리도 처리한다, 도메인 검증도 처리한다.
이 모두 결국엔 현재 테스트에 파생되는 모든 검증, 예외 로직을 처리할 것인가에 대해 정확하기 이야기 안되서 인 것 같아요.
그래서 가장 큰 틀로 오늘 조금 이야기 한 주제인 '서비스 테스트는(이 외에도) 어디까지 테스트를 고려할 것인가?'에 대해 이야기해보면 좋을 것 같아요 ~
이번 계기로 생각해보니 저는 1번 방식을 선호합니다. 그렇지 않으면 로직을 분리할수록 중복되는 테스트 코드가 너무 많아질 것 같아요.
그래서 블랙박스 테스트로 연관된 클래스를 고려하지 않고, 해당 클래스와 해당 클래스의 용도만 생각했을 때 실패 케이스를 작성하는 방식으로 테스트를 구현하는 것이 좋을 것 같아요 ~
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
직접적으로 도메인 검증 로직을 호출하는 서비스에서는 처리해야하고, 위에 말했듯이 직접 사용하지 않는 상위 서비스에서는 하지 않아도 될 것 같습니다.
도메인 규칙은 맞는 것 같아요
Dto와 도메인 두군데에서 중복 검증해야할 것 같네요
컨트롤러는 요청을 받아 넘겨주고 반환하는 역할, 서비스는 받은 요청에 따른 비즈니스 로직을 처리하는 역할이라고 생각합니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
앗 저도 제우스 의견에 더 가깝네요.
도메인의 예외 처리에 대한 테스트는 도메인 테스트에서 확인을 하면 될 것 같군요.
추가적인 예외처리가 있는 경우에만 서비스 테스트에서 추가 확인을 해 주어도 될 것 같아요~
켬미가 고정해 준 이야기 주제에선 저도 1번 방법을 선호합니다!