-
Notifications
You must be signed in to change notification settings - Fork 0
[Feat] 나만의 맛집 코멘트 등록 API 구현 #90
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
base: develop
Are you sure you want to change the base?
Conversation
""" Walkthrough이번 변경에서는 "응원(cheer)" 등록 API와 관련된 도메인, 서비스, 컨트롤러, 테스트, 문서화 코드가 대거 추가 및 개선되었습니다. 또한, 가게 카테고리 타입이 문자열에서 Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant CheerController
participant CheerService
participant MapClient
participant StoreSearchFilter
participant StoreRepository
participant MemberRepository
participant ImageService
Client->>CheerController: POST /api/cheer (multipart: request, image)
CheerController->>CheerService: registerCheer(request, image, memberId)
CheerService->>MapClient: searchShops(request.storeName)
MapClient-->>CheerService: List<StoreSearchResult>
CheerService->>StoreSearchFilter: filterStoreByKakaoId(results, request.storeKakaoId)
StoreSearchFilter-->>CheerService: StoreSearchResult
CheerService->>ImageService: upload(image, "CHEER")
ImageService-->>CheerService: imageKey
CheerService->>MemberRepository: findById(memberId)
MemberRepository-->>CheerService: Member
CheerService->>StoreRepository: findByKakaoId(kakaoId)
alt Store exists
StoreRepository-->>CheerService: Optional<Store>
else Store not exists
CheerService->>StoreRepository: save(Store)
StoreRepository-->>CheerService: Store
end
CheerService->>CheerRepository: save(Cheer)
CheerRepository-->>CheerService: Cheer
CheerService->>ImageService: getPresignedUrl(imageKey)
ImageService-->>CheerService: imageUrl
CheerService-->>CheerController: CheerResponse
CheerController-->>Client: 201 Created + CheerResponse
Possibly related PRs
Suggested labels
Poem
""" 📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
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.
Actionable comments posted: 4
🧹 Nitpick comments (1)
src/test/java/eatda/client/map/StoreSearchResultTest.java (1)
33-50
: 테스트 커버리지 확장을 권장합니다.현재는 한식과 기타 카테고리만 테스트하고 있습니다. 다른 카테고리들(중식, 일식, 양식 등)에 대한 테스트도 추가하면 더 안전할 것 같습니다.
다음과 같이 파라미터화된 테스트로 확장할 수 있습니다:
@ParameterizedTest @CsvSource({ "'음식점 > 중식 > 짜장면', CHINESE", "'음식점 > 일식 > 초밥', JAPANESE", "'음식점 > 양식 > 파스타', WESTERN", "'음식점 > 카페 > 커피', CAFE" }) void 다양한_카테고리_매핑을_검증한다(String categoryName, StoreCategory expected) { // test implementation }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
src/test/resources/test/test-image.png
is excluded by!**/*.png
📒 Files selected for processing (23)
src/main/java/eatda/client/map/StoreSearchResult.java
(3 hunks)src/main/java/eatda/controller/store/CheerController.java
(1 hunks)src/main/java/eatda/controller/store/CheerRegisterRequest.java
(1 hunks)src/main/java/eatda/controller/store/CheerResponse.java
(1 hunks)src/main/java/eatda/controller/story/FilteredSearchResult.java
(1 hunks)src/main/java/eatda/domain/store/Store.java
(0 hunks)src/main/java/eatda/domain/store/StoreCategory.java
(1 hunks)src/main/java/eatda/domain/story/Story.java
(5 hunks)src/main/java/eatda/repository/store/StoreRepository.java
(1 hunks)src/main/java/eatda/service/common/ImageDomain.java
(1 hunks)src/main/java/eatda/service/store/CheerService.java
(1 hunks)src/main/java/eatda/service/store/StoreSearchFilter.java
(2 hunks)src/main/java/eatda/service/story/StoryService.java
(4 hunks)src/test/java/eatda/client/map/StoreSearchResultTest.java
(1 hunks)src/test/java/eatda/controller/store/CheerControllerTest.java
(1 hunks)src/test/java/eatda/controller/story/StoryControllerTest.java
(5 hunks)src/test/java/eatda/document/RestDocsRequest.java
(3 hunks)src/test/java/eatda/document/store/CheerDocumentTest.java
(1 hunks)src/test/java/eatda/document/story/StoryDocumentTest.java
(5 hunks)src/test/java/eatda/domain/story/StoryTest.java
(10 hunks)src/test/java/eatda/service/store/CheerServiceTest.java
(1 hunks)src/test/java/eatda/service/story/StoryServiceTest.java
(4 hunks)src/test/java/eatda/util/MappingUtils.java
(1 hunks)
💤 Files with no reviewable changes (1)
- src/main/java/eatda/domain/store/Store.java
🧰 Additional context used
🧠 Learnings (4)
src/main/java/eatda/controller/store/CheerController.java (1)
Learnt from: leegwichan
PR: YAPP-Github/26th-Web-Team-1-BE#60
File: src/main/java/eatda/controller/store/StoreController.java:18-21
Timestamp: 2025-07-09T08:05:53.497Z
Learning: Spring Boot 컨트롤러에서 LoginMember 등의 인증 파라미터는 메서드 내에서 직접 사용되지 않더라도 접근 제어(인증된 사용자만 접근 가능)를 위해 필요할 수 있다. 이는 보안상 유효한 패턴이다.
src/test/java/eatda/controller/story/StoryControllerTest.java (1)
Learnt from: leegwichan
PR: YAPP-Github/26th-Web-Team-1-BE#60
File: src/test/java/eatda/controller/store/StoreControllerTest.java:10-32
Timestamp: 2025-07-09T07:56:50.612Z
Learning: 컨트롤러 테스트에서 MockitoBean으로 의존성을 모킹한 경우, 상세한 비즈니스 로직 검증보다는 컨트롤러 계층의 동작(라우팅, 파라미터 처리, 응답 구조 등)을 검증하는 것이 더 적절합니다. 모킹된 데이터에 대한 상세 검증은 의미가 없기 때문입니다.
src/main/java/eatda/service/story/StoryService.java (1)
Learnt from: leegwichan
PR: YAPP-Github/26th-Web-Team-1-BE#60
File: src/main/java/eatda/client/map/MapClient.java:24-41
Timestamp: 2025-07-09T07:54:18.446Z
Learning: In MapClient.java, the developer prefers to keep Kakao API-specific values (baseUrl, pageSize) hardcoded rather than extracting them to configuration properties, as these values are inherently tied to the Kakao API specification.
src/test/java/eatda/controller/store/CheerControllerTest.java (1)
Learnt from: leegwichan
PR: YAPP-Github/26th-Web-Team-1-BE#60
File: src/test/java/eatda/controller/store/StoreControllerTest.java:10-32
Timestamp: 2025-07-09T07:56:50.612Z
Learning: 컨트롤러 테스트에서 MockitoBean으로 의존성을 모킹한 경우, 상세한 비즈니스 로직 검증보다는 컨트롤러 계층의 동작(라우팅, 파라미터 처리, 응답 구조 등)을 검증하는 것이 더 적절합니다. 모킹된 데이터에 대한 상세 검증은 의미가 없기 때문입니다.
🧬 Code Graph Analysis (4)
src/main/java/eatda/controller/store/CheerController.java (1)
src/main/java/eatda/controller/web/auth/AuthMemberArgumentResolver.java (1)
RequiredArgsConstructor
(14-36)
src/main/java/eatda/service/store/CheerService.java (1)
src/main/java/eatda/service/store/StoreService.java (1)
Service
(21-54)
src/test/java/eatda/controller/story/StoryControllerTest.java (1)
src/test/java/eatda/util/MappingUtils.java (1)
MappingUtils
(6-20)
src/test/java/eatda/document/story/StoryDocumentTest.java (3)
src/test/java/eatda/document/RestDocsRequest.java (1)
RestDocsRequest
(22-90)src/test/java/eatda/document/RestDocsResponse.java (1)
RestDocsResponse
(14-40)src/test/java/eatda/util/MappingUtils.java (1)
MappingUtils
(6-20)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: test
🔇 Additional comments (53)
src/test/java/eatda/util/MappingUtils.java (1)
1-21
: 테스트 유틸리티 클래스가 잘 설계되었습니다.Jackson ObjectMapper를 사용한 JSON 직렬화 유틸리티가 적절하게 구현되었습니다. final 클래스로 선언하고 private 생성자를 통해 인스턴스화를 방지한 점이 좋습니다.
src/main/java/eatda/controller/story/FilteredSearchResult.java (2)
3-3
: StoreCategory import 추가가 적절합니다.String에서 StoreCategory enum으로의 타입 변경을 지원하기 위한 import 문이 올바르게 추가되었습니다.
10-10
: 타입 안전성이 개선되었습니다.category 필드의 타입을 String에서 StoreCategory enum으로 변경한 것은 타입 안전성과 도메인 모델의 일관성을 크게 향상시킵니다.
src/test/java/eatda/service/story/StoryServiceTest.java (3)
14-14
: StoreCategory import 추가가 적절합니다.테스트 코드에서 enum 타입을 사용하기 위한 import 문이 올바르게 추가되었습니다.
82-82
: enum 사용으로 타입 안전성이 향상되었습니다.하드코딩된 "한식" 문자열을
StoreCategory.KOREAN
enum으로 변경한 것은 타입 안전성과 유지보수성을 크게 개선합니다. 테스트 데이터 구성에서 일관된 enum 사용이 좋습니다.Also applies to: 93-93, 128-128
141-141
: 응답 검증에서 문자열 사용이 적절합니다.141번 라인에서
"한식"
문자열을 사용한 것은 API 응답에서 클라이언트가 받게 될 실제 한국어 문자열을 검증하는 것으로 적절합니다. 도메인에서는 enum을 사용하고 응답에서는 사용자 친화적인 문자열로 변환하는 것이 올바른 설계입니다.src/main/java/eatda/service/common/ImageDomain.java (1)
12-14
: 새로운 이미지 도메인 추가가 적절합니다.
STORY
와CHEER
도메인 추가는 새로운 기능 구현을 위해 필요한 변경사항입니다. 기존 enum 구조와 일관되게 구현되어 확장성이 좋습니다.src/main/java/eatda/repository/store/StoreRepository.java (2)
5-5
: Optional import 추가가 적절합니다.새로운 메서드의 반환 타입을 위한 import 문이 올바르게 추가되었습니다.
13-13
: kakaoId로 Store 조회하는 메서드가 적절합니다.
findByKakaoId
메서드 추가는 cheer 등록 기능에서 기존 스토어를 찾거나 새로 생성하는 로직에 필요한 변경사항입니다.Optional<Store>
반환 타입은 엔티티가 존재하지 않을 수 있는 상황을 적절히 처리합니다.src/main/java/eatda/domain/store/StoreCategory.java (1)
16-16
: 디저트에서 베이커리로 카테고리 변경이 적절합니다.비즈니스 요구사항에 맞게 카테고리가 업데이트되었고, 기존의 validation 로직이 잘 유지되고 있습니다.
src/test/java/eatda/domain/story/StoryTest.java (2)
7-7
: StoreCategory enum 타입 전환이 적절하게 적용되었습니다.도메인 모델의 변경사항이 테스트에도 일관되게 반영되었습니다.
29-29
: 테스트 데이터의 enum 전환이 올바르게 수행되었습니다.String 리터럴에서 StoreCategory.KOREAN enum으로의 변경이 모든 테스트 케이스에 일관되게 적용되었고, null 검증 테스트도 적절하게 업데이트되었습니다.
Also applies to: 51-51, 72-72, 86-86, 103-103, 120-120, 137-137, 161-161, 178-178
src/main/java/eatda/service/store/StoreSearchFilter.java (1)
18-24
: 카카오 ID로 가게를 필터링하는 메서드가 잘 구현되었습니다.기존 검증 로직(
isValidStore
)을 재사용하고 적절한 예외 처리를 포함하여 좋은 설계입니다.src/main/java/eatda/controller/store/CheerController.java (1)
23-30
: 응원 등록 API 엔드포인트가 잘 구현되었습니다.
- REST 규칙에 맞는 POST 메서드와 201 Created 상태 코드 사용
- multipart/form-data 형태의 요청 처리가 적절함
- 서비스 계층으로의 적절한 책임 분리
- LoginMember를 통한 인증 처리가 올바름
src/main/java/eatda/client/map/StoreSearchResult.java (2)
23-32
: 카테고리 매핑이 잘 구현되었습니다.접두사 기반 매핑 방식이 명확하고 유지보수하기 좋습니다. 카카오 API의 카테고리 명명 규칙에 맞춰 적절히 구현되었습니다.
54-66
: 도메인 객체 변환 로직이 잘 구현되었습니다.빌더 패턴을 사용하여 깔끔하게 Store 객체를 생성하고 있으며,
getStoreCategory()
메서드를 활용한 것도 좋습니다.src/test/java/eatda/client/map/StoreSearchResultTest.java (1)
14-31
: 테스트 케이스가 적절합니다.한식 카테고리 매핑을 올바르게 검증하고 있습니다. 테스트 데이터도 실제적이고 명확합니다.
src/main/java/eatda/controller/store/CheerResponse.java (1)
6-21
: 잘 설계된 응답 DTO입니다.record 구조가 깔끔하고, 도메인 객체를 받는 생성자를 통해 변환 로직이 캡슐화되어 있어 좋습니다.
src/test/java/eatda/controller/store/CheerControllerTest.java (2)
22-39
: 멀티파트 요청 테스트가 잘 구현되었습니다.이미지 파일과 JSON 요청을 포함한 멀티파트 요청 테스트가 적절하게 작성되었습니다. 인증 헤더와 응답 상태 코드 검증도 포함되어 있어 좋습니다.
41-57
: 이미지 없는 경우의 테스트도 포함되어 완성도가 높습니다.선택적인 이미지 업로드 기능을 고려한 테스트 케이스가 잘 작성되었습니다. 컨트롤러 계층 테스트에 적합한 수준의 검증을 하고 있습니다.
src/main/java/eatda/service/store/CheerService.java (1)
28-33
: 의존성 주입이 적절하게 구성되었습니다.필요한 모든 의존성이 명확하게 정의되어 있고, 단일 책임 원칙을 잘 지키고 있습니다.
src/test/java/eatda/document/RestDocsRequest.java (3)
6-7
: 멀티파트 요청 문서화를 위한 import 추가가 적절합니다.멀티파트 형식 요청 문서화에 필요한 Spring REST Docs 유틸리티들이 올바르게 import되었습니다.
Also applies to: 10-10, 19-19
67-70
: 멀티파트 필드 문서화 메서드가 잘 구현되었습니다.
requestParts()
를 사용하여 멀티파트 요청 부분을 문서화하는 메서드가 기존 패턴과 일관성 있게 구현되었습니다.
77-81
: 멀티파트 필드별 상세 문서화 메서드가 유용합니다.특정 멀티파트 필드에 대해
requestPartBody
와requestPartFields
를 모두 추가하는 오버로드된 메서드가 잘 설계되었습니다. 이는 JSON 요청 부분과 해당 필드들을 함께 문서화할 때 유용할 것입니다.src/test/java/eatda/controller/story/StoryControllerTest.java (5)
10-10
: 테스트 개선을 위한 import 추가가 적절합니다.
ResourceUtils.getFile()
,MappingUtils.toJsonBytes()
,FileNotFoundException
을 import하여 테스트의 타입 안전성과 일관성을 개선했습니다.Also applies to: 15-15, 17-17
75-76
: 문자열 리터럴 포맷팅 개선이 적절합니다.긴 URL 문자열을 여러 줄로 나누어 가독성을 개선했습니다.
98-114
: 응답 처리 방식이 크게 개선되었습니다.중간
Response
객체 대신 직접StoryResponse
로 추출하고assertAll
을 사용하여 테스트 가독성과 유지보수성이 향상되었습니다.
124-129
: 에러 테스트 코드가 간소화되었습니다.중간 변수 없이 직접 체이닝하여 코드가 더욱 간결해졌습니다.
36-43
: 스토리 등록 멀티파트 테스트 개선 사항 승인
StoryRegisterRequest
객체 활용과ResourceUtils.getFile()
적용으로 타입 안전성과 가독성 향상됨을 확인했습니다.- 테스트 이미지 파일(
src/test/resources/test/test-image.png
)도 정상적으로 존재함을 확인했습니다.위 변경사항을 승인합니다.
src/test/java/eatda/service/store/CheerServiceTest.java (5)
5-6
: 응원 등록 테스트를 위한 import가 적절히 추가되었습니다.
CheerRegisterRequest
,CheerResponse
,StoreSearchResult
등 응원 등록 기능 테스트에 필요한 클래스들이 올바르게 import되었습니다.Also applies to: 8-10, 16-17, 21-22
29-43
: 외부 의존성 모킹이 적절합니다.
mapClient.searchShops()
를 현실적인 데이터로 모킹하여 테스트의 독립성을 보장했습니다. 검색 결과 데이터가 포괄적이고 실제 API 응답과 유사합니다.
45-59
: 새로운 가게 등록 시나리오 테스트가 잘 구현되었습니다.가게가 DB에 없을 때 가게와 응원을 모두 저장하는 로직을 올바르게 테스트하고 있습니다.
MockMultipartFile
사용과assertAll
을 통한 검증이 적절합니다.
61-77
: 기존 가게 응원 등록 테스트가 적절합니다.가게가 이미 존재할 때 응원만 저장하는 로직을 검증하며, 기존 가게 ID가 유지되는지 확인하는 검증 로직이 우수합니다.
79-92
: 이미지 null 처리 테스트가 중요합니다.선택적 이미지 파일에 대한 null 처리를 테스트하여 견고성을 확보했습니다. 이미지가 없어도 응원 등록이 가능한 비즈니스 요구사항을 잘 반영합니다.
src/test/java/eatda/document/store/CheerDocumentTest.java (6)
3-3
: 응원 등록 API 문서화를 위한 import가 적절합니다.멀티파트 요청 문서화, 유틸리티, 예외 처리에 필요한 클래스들이 올바르게 import되었습니다.
Also applies to: 5-6, 9-9, 15-16, 28-28, 30-30, 36-36
41-55
: 멀티파트 요청 문서화가 상세하고 명확합니다.이미지 파트(선택적)와 요청 정보 파트에 대한 문서화가 잘 구성되어 있으며, JSON 필드 타입과 설명이 적절합니다.
57-63
: 응답 문서화가 포괄적입니다.응답 필드들의 타입과 설명이 명확하게 정의되어 있으며, 선택적 필드(
imageUrl
)도 적절히 표시되었습니다.
65-83
: 성공 시나리오 테스트가 잘 구현되었습니다.실제 파일을 사용한 멀티파트 요청과 서비스 모킹이 적절하며, 201 상태 코드 검증이 올바릅니다.
85-111
: 다양한 에러 시나리오를 포괄하는 매개변수화 테스트가 우수합니다.인증, 토큰 만료, 외부 서비스 오류, 파일 업로드 실패 등 주요 에러 케이스들을 체계적으로 테스트하고 문서화합니다.
116-116
: 중첩 클래스명 변경이 명확성을 개선합니다.
Get
에서GetCheers
로 변경하여 클래스의 목적이 더욱 명확해졌습니다.src/main/java/eatda/domain/story/Story.java (4)
5-5
: 타입 안전성 향상을 위한 import 추가가 적절합니다.
StoreCategory
enum과 JPA의@Enumerated
어노테이션을 import하여 문자열에서 enum으로의 전환을 지원합니다.Also applies to: 10-11
50-52
: enum 타입으로의 변경과 JPA 매핑이 올바릅니다.
@Enumerated(EnumType.STRING)
어노테이션을 사용하여 데이터베이스에 enum의 문자열 값이 저장되도록 설정했습니다. 이는 데이터베이스 호환성과 가독성을 보장합니다.
64-64
: 생성자와 검증 메서드 시그니처 업데이트가 일관적입니다.생성자 매개변수와 검증 메서드의 타입이
StoreCategory
로 일관되게 변경되었습니다.Also applies to: 93-93
134-137
: enum 검증 로직이 적절히 간소화되었습니다.enum 타입 사용으로 인해 유효하지 않은 카테고리 값을 컴파일 타임에 방지할 수 있어, null 체크만으로 충분한 검증이 가능합니다.
src/main/java/eatda/service/story/StoryService.java (3)
3-3
: 의존성 변경이 적절히 적용되었습니다.
StoreService
에서MapClient
로의 의존성 변경이 일관성 있게 적용되어 있습니다. 이는 가게 검색 로직의 직접적인 접근을 가능하게 하는 좋은 아키텍처 개선입니다.Also applies to: 31-31
66-66
: 타입 안전성 개선이 잘 적용되었습니다.
store.getStoreCategory()
호출을 통해StoreCategory
enum을 사용하는 것은 타입 안전성을 크게 향상시킵니다. 문자열 기반 카테고리에서 enum으로의 전환이 적절히 이루어졌습니다.
39-39
: mapClient.searchShops 시그니처와 반환 타입이 올바릅니다
- src/main/java/eatda/client/map/MapClient.java:24 에 정의된
public List<StoreSearchResult> searchShops(String query)
메서드가List<StoreSearchResult>
를 반환하도록 구현되어 있어,
StoryService.java(39행)의 호출 구문(mapClient.searchShops(request.query())
)과 일치합니다.- 별도의 수정은 필요하지 않습니다.
src/test/java/eatda/document/story/StoryDocumentTest.java (6)
43-50
: 멀티파트 필드 문서화가 크게 개선되었습니다.멀티파트 요청의 각 부분(
image
,request
)에 대한 명확한 설명과 요청 본문 필드 문서화가 추가되어 API 문서의 품질이 향상되었습니다.requestBodyField("request", ...)
사용으로 멀티파트 내 JSON 구조를 정확히 문서화했습니다.
54-55
: 타입 안전한 요청 객체 사용이 우수합니다.
StoryRegisterRequest
객체를 사용하고MappingUtils.toJsonBytes()
로 직렬화하는 방식이 기존의 원시 JSON 문자열보다 훨씬 타입 안전하고 유지보수하기 쉽습니다. 클래스패스 리소스에서 테스트 이미지를 로드하는 것도 적절한 접근입니다.Also applies to: 64-65
72-72
: 일관된 타입 안전성 적용을 확인합니다.실패 테스트에서도 동일한
StoryRegisterRequest
객체와MappingUtils.toJsonBytes()
패턴을 사용하여 일관성을 유지했습니다. 이는 테스트 코드의 품질과 유지보수성을 향상시킵니다.Also applies to: 86-86
110-127
: 테스트 구조가 크게 개선되었습니다.목 설정과 응답 객체 생성을 직접적으로 처리하여 테스트 코드가 더 명확하고 이해하기 쉬워졌습니다. HTTP 상태 코드 검증에 집중한 것도 적절합니다.
152-171
: 스토리 상세 조회 테스트가 잘 단순화되었습니다.응답 객체를 직접 생성하고 서비스 호출을 목킹하는 방식이 명확합니다. 테스트의 목적과 검증 포인트가 명확히 드러나는 좋은 구조입니다.
65-65
: 테스트 이미지 파일이 정상적으로 존재합니다
src/test/resources/test/test-image.png
경로에 테스트 이미지가 확인되었습니다. 추가 작업은 필요하지 않습니다.
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.
이번 PR도 고생하셨습니다! 🎉
이번 2개 PR은 변경점이 많아서 보는데 시간이 오래걸렸네요
코멘트 남겼으니 확인해주세요~
|
||
response.then() | ||
.statusCode(200) | ||
.body("storeKakaoId", equalTo("123456")) |
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.
이전 PR에서 명확하게 정해지지는 않았는데,
응답 바디 검증이 삭제됐네요
회의에서 논의하면 되려나요?
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.
넵, 회의 문서에 DocumentTest와 관련한 부분을 적어두었습니다. 오늘 회의에서 논의하고 의견 맞춰보도록 하죠!
.multiPart("request", "request.json", requestJson.getBytes(StandardCharsets.UTF_8), "application/json") | ||
.multiPart("image", "image.png", imageBytes, "image/png") | ||
.multiPart("request", "request.json", MappingUtils.toJsonBytes(request), "application/json") | ||
.multiPart("image", getFile("classpath:test/test-image.png")) |
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.
실제 파일을 리소스에 넣고 테스트하게 바뀌었는데 이렇게 했을때 장점이 무엇일까요?
Rest Assured를 이용한 테스트의 특징은 "실제 Spring 환경의 DispatcherServlet을 띄워서 테스트를 진행"한다는 점에 있다고 생각합니다. 그래서 Rest Assured Test 만큼은 최대한 실제 이미지 파일을 사용하려고 노력했습니다.
테스트가 특정 파일에 의존하게 되는것 같기도 한데..
해당 테스트는 test/test-image.png
경로에 무조건 이미지가 있어야 하고, 만약에 요구사항이 바뀌면 이미지 이름이 쓰여있는 곳마다 전부 바꿔줘야 한다는 단점이 있겠네요. 그러면 아래와 같은 테스트 유틸을 만들어 사용하는 건 어떨까요?
public class ImageUtils {
public MultipartFile getTestImage() {
return getFile("classpath:test/test-image.png"); // 요구 사항이 바뀌면, 해당 부분만 바꾸어 주면 됩니다.
}
}
} | ||
|
||
@Test | ||
void 스토리_등록_실패_필수값_누락() { |
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.
이것도 오늘 회의에서 논의하시죠!
private MappingUtils() { | ||
} | ||
|
||
public static byte[] toJsonBytes(Object object) { |
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.
기존 requestJson으로 하나씩 넣어줘야 했던걸
객체를 받아서 요청을 생성해주네요 👍🏻
private final ImageService imageService; | ||
private final StoryRepository storyRepository; | ||
private final MemberRepository memberRepository; | ||
|
||
@Transactional | ||
public void registerStory(StoryRegisterRequest request, MultipartFile image, Long memberId) { | ||
Member member = memberRepository.getById(memberId); | ||
List<StoreSearchResult> searchResponses = storeService.searchStoreResults(request.query()); | ||
List<StoreSearchResult> searchResponses = mapClient.searchShops(request.query()); |
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.
[질문]
지금 요구사항상 스토어와 스토리는 완전 분리되는게 차라리 낫겠군요
그래서 MapClient를 따로 들고있게 하신건가요?
그런데 StoreService 가 가게 정보를 전부 책임지는 객체로 본다면
StoreService 내부적으로 내부 api 호출과 외부 api 호출을 메서드로 분리해서 가지고 있는것도 나쁘지 않을것 같군요
여기서 서비스들간 의존을 하지말자... 이 맥락이 같이 나올것 같은데..
이건 이번 발표자료에 넣어서 더 좋은 방법이 있나 찾아보는것도 좋을것 같아요
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.
지금 요구사항상 스토어와 스토리는 완전 분리되는게 차라리 낫겠군요
그래서 MapClient를 따로 들고있게 하신건가요?
넵. '스토어와 스토리의 분리'의 관점도 있지만 '서비스끼리의 참조' 관점도 있었습니다.
그런데 StoreService 가 가게 정보를 전부 책임지는 객체로 본다면
StoreService 내부적으로 내부 api 호출과 외부 api 호출을 메서드로 분리해서 가지고 있는것도 나쁘지 않을것 같군요
- Q. 내부 API 호출, 외부 API 호출은 각각 무엇을 의미하는 걸까요?
- 저는 저희 DB에 있는 Stroe 관련 정보는 StoreRepository를 이용하고, 외부 API를 이용한 Store 호출은 MapClient와 StoreSearchFilter를 이용한다고 생각했습니다.
String imageKey = imageService.upload(image, ImageDomain.CHEER); | ||
|
||
Store store = storeRepository.findByKakaoId(result.kakaoId()) | ||
.orElseGet(() -> storeRepository.save(result.toStore())); |
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.
store 테이블에 kakaoId가 유니크라서
이 부분은 동시성 문제가 있을수 있지않나요?
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.
바로 TODO 주석 & 리팩토링 이슈 추가해 놓겠습니다.
|
✨ 개요
🧾 관련 이슈
closed #52
🔍 참고 사항 (선택)
StoryControllerTest
를 개선하였으니, 확인 부탁드립니다!RestDocsRequest
의 기능을 추가했습니다.StoryDocumentTest
를 개선하였으니, 확인 부탁드립니다!Summary by CodeRabbit
신규 기능
버그 수정
리팩터
테스트
문서화
기타