Skip to content
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

[디디] API 테스트/문서자동화 미션 제출합니다. #26

Merged
merged 30 commits into from
Jun 2, 2020

Conversation

fucct
Copy link

@fucct fucct commented May 27, 2020

안녕하세요 리뷰어님!
이번 미션 진행하면서 궁금했던 점들을 정리해보았습니다. 답변주시면 감사하겠습니다.😄

  • 인수테스트와 api 테스트 둘 다 예외사항에 대한 테스트를 추가해야 하는지, 아니면 하나만 정해서 추가하면 되는지 정확하지 않네요.. 만약 정해서 한다면 어느곳에 두는게 적절할지도 답변주시면 감사하겠습니다
  • 인수테스트에서 Junit5의 다이나믹 테스트를 이용하면 유용하다는 걸 알게 되었는데요, 문제는 이전 테스트에서 사용한 변수를 다음 테스트에서 사용할 수 없다는 점이였습니다. 방법이 있는데 제가 찾지 못한걸까요? 아니면 방법이 없지만 감수하고 사용하는 걸까요..?😭
  • Spring data Jdbc 관련 질문입니다. 제가 DDD에 대한 기본 지식이 너무 부족해서 어떻게 보면 사소한 질문일수도 있습니다. 또한 미션을 진행하면서 제가 떠오른 궁금증이라 미션과 관련이 깊지 않을 것 같아서 질문 드려도 될 지 모르겠네요..😭 첫번째 질문은 어떠한 엔티티에 진입 가능한 root가 여러개라면, 해당 엔티티는 어떠한 Aggregate에도 포함되지 않는 엔티티인가요? 예를 들면 Article을 통해 그 게시물에 달린 Comment에 접근이 가능하고, User를 통해 User가 작성한 Comment에도 접근 가능하다면, Comment는 독립적인 Aggregate가 되는걸까요..?
  • 두번째 질문은, 제 질문이 맞다면, 각각의 관계에 있어서 Ref Table이 반드시 존재해야 하나요? 예를 들면 Article 이 삭제될 때 Comment도 같이 삭제되길 원하더라도 독립된 Aggregate이므로 ref Table 을 두고, 로직에서 삭제를 하는게 맞나요? 이렇게되면 하나의 Transaction에서 처리가 불가능할 것 같아서 궁금증이 생겼습니다.

리뷰 감사드립니다😄

fucct added 29 commits May 19, 2020 17:04
- 문서화 실습 구현
- 인증 실습 구현
- 패스워드 일치
- 이메일 중복
- 전체 테스트 정상화
- 문서화 추가 양식 구현 (필수값 여부, 입력값 foramt)
- 예외 사항 추가
- 토큰이 없는 경우 정보조회 테스트 추가
- 즐겨찾기 삭제 테스트 및 구현
- 패키지 구조 수정
- GlobalExceptionHandler 수정
- exception 상속 관계 수정
- 인터셉터 path 추가
- exception handler 수정
- 예외 사항에 대한 인수테스트 추가
- 예외사항에 대한 문서화 완료
@phs1116
Copy link

phs1116 commented May 31, 2020

  • 인수테스트와 api 테스트 둘 다 예외사항에 대한 테스트를 추가해야 하는지, 아니면 하나만 정해서 추가하면 되는지 정확하지 않네요.. 만약 정해서 한다면 어느곳에 두는게 적절할지도 답변주시면 감사하겠습니다

전체 유저스토리가 아닌 api 단위에서의 예외에 대해서는 예외테스트를 작성해주는게 좋을 것 같네요. :)
정확히는 예외 테스트라기 보다는 응답 status code에 대한 테스트라고 볼수도 있겠네요.

  • 인수테스트에서 Junit5의 다이나믹 테스트를 이용하면 유용하다는 걸 알게 되었는데요, 문제는 이전 테스트에서 사용한 변수를 다음 테스트에서 사용할 수 없다는 점이였습니다. 방법이 있는데 제가 찾지 못한걸까요? 아니면 방법이 없지만 감수하고 사용하는 걸까요..?😭

질문에 대해서 이해가 잘 안가는데요, 이전 테스트에서 사용한 변수라는게 어떤 변수를 뜻하는건지 알 수 있을까요? :)

  • Spring data Jdbc 관련 질문입니다. 제가 DDD에 대한 기본 지식이 너무 부족해서 어떻게 보면 사소한 질문일수도 있습니다. 또한 미션을 진행하면서 제가 떠오른 궁금증이라 미션과 관련이 깊지 않을 것 같아서 질문 드려도 될 지 모르겠네요..😭 첫번째 질문은 어떠한 엔티티에 진입 가능한 root가 여러개라면, 해당 엔티티는 어떠한 Aggregate에도 포함되지 않는 엔티티인가요? 예를 들면 Article을 통해 그 게시물에 달린 Comment에 접근이 가능하고, User를 통해 User가 작성한 Comment에도 접근 가능하다면, Comment는 독립적인 Aggregate가 되는걸까요..?

이러한 컨텍스트 분리는 관점을 어떻게 가져가냐에 따라 다를 것 같아요. 고민해볼 요소가 많은 부분이구요.
그리고 비즈니스 적인 부분에 대해서 Aggregate를 통한 로직을 풀어내는건 용이하지만,
(비즈니스 관점에서 Aggregate를 풀어나간다면 Member, Article-Comment가 더 적합하겠네요. :)
방금 말씀하신 특정 데이터의 Query 부분에 대해서는 Aggregate로만 한정하기엔 쉽지 않은 부분이 많아요. :)

  • 두번째 질문은, 제 질문이 맞다면, 각각의 관계에 있어서 Ref Table이 반드시 존재해야 하나요? 예를 들면 Article 이 삭제될 때 Comment도 같이 삭제되길 원하더라도 독립된 Aggregate이므로 ref Table 을 두고, 로직에서 삭제를 하는게 맞나요? 이렇게되면 하나의 Transaction에서 처리가 불가능할 것 같아서 궁금증이 생겼습니다.

별도의 Aggregate를 분리한다고 해도, Ref Table이 없이 Comment가 직접 Article의 레퍼런스를 가지고 있어도 되는 부분 아닌가요? :)
현재는 같은 서비스 내에 존재하니 트랜잭션에는 큰 문제가 없을 것 같은데, 별도 서비스라면 보상 트랜잭션에 대해서 고민을 해봐야겠죠. :)

Copy link

@phs1116 phs1116 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

안녕하세요, 디디!
구현 깔끔하게 잘해주셨어요!
피드백 몇가지랑 질문에 대한 답 추가했는데 참고 부탁드릴게요! :)

@fucct fucct closed this Jun 1, 2020
@fucct fucct reopened this Jun 1, 2020
- Auth enum 제거
- Interceptor 전체 url 적용
- Favorite equals, hashcode 재정의 삭제
- logger 적용
- transaction 적용
- Favorite을 aggregate root로 수정
@fucct
Copy link
Author

fucct commented Jun 1, 2020

좋은 피드백 감사합니다! 많은걸 배우게 되네요!

두 번째 질문은 다이나믹 테스트의 한 테스트에서 사용한 변수를 다른 테스트에서 쓸 수 있는지에 대한 질문이었습니다! 예를 들자면 첫 번째 테스트에서 int a = 1를 선언하고 두 번째 테스트에서 a변수를 쓸 수 있는 방법이 있는지에 대한 질문이였습니다. 사소한 질문이라 답변 안주셔도 될 것 같습니다!

그리고 마지막 질문에 제가 직접 레퍼런스를 갖는 방법을 놓치고 있어서 질문이 이상했네요 😅 (Member와 Favorite에서 직접 레퍼런스를 갖는 방식으로 수정해보면서 익혔습니다..!) 추가 질문을 드리자면 ref 테이블은 어떤경우에 갖는게 좋을까요..? 답변주시면 감사하겠습니다!

@phs1116
Copy link

phs1116 commented Jun 2, 2020

추가 질문을 드리자면 ref 테이블은 어떤경우에 갖는게 좋을까요..?
경우가 다양하겠네요. 양쪽 도메인간의 동일 레벨의 모델이 있을 경우, 서로의 키의 체번이 다르게 될테니 이를 매핑하기 위해 사용할수도 있을 거구요. 하지만 이런 경우도 포함하여 레퍼런스 테이블을 가져가지 않고 모델 내에 레퍼런스 키를 가져는 방식으로 해도 충분한 것 같아요.. :)

Copy link

@phs1116 phs1116 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

안녕하세요. 리뷰어 화투입니다.
피드백 반영 잘해주셨어요.
크게 피드백 드릴 내용이 없어서 머지할게요. :)
간단한 피드백이랑 질문 답 추가했는데 참고 부탁드려요!

favoriteRepository.delete(favorite);
}

private Favorite getFavorite(Member member, FavoriteRequest request) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getFavorite보다는 생성한다는 의미를 가지는게 더 적합하지 않을까요?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

수정했습니다! 자세하게 설명해주셔서 감사합니다!

@phs1116 phs1116 merged commit 40c254d into woowacourse:fucct Jun 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants