refactor: User controller, service 계층 리팩토링/테스트 코드 추가 #104
Conversation
|
""" Walkthrough사용자 생성 및 중복 검사 로직이 서비스 계층에서 모듈화되어, 검증, 저장, 토큰 발급 기능이 분리되었습니다. 컨트롤러의 사용자명 중복 검사 응답이 단순화되었고, 관련 단위 테스트가 새롭게 작성 및 리팩토링되었습니다. DTO의 코드 스타일이 개선되었습니다. Changes
Sequence Diagram(s)sequenceDiagram
participant Controller as UserController
participant Service as UserService
participant Repo as UserRepository
participant Token as JwtTokenProvider
participant Refresh as RefreshTokenService
Controller->>Service: createUser(request)
Service->>Service: isDuplicatedEmailUsername(request)
Service->>Repo: existsByEmail(request.email)
Service->>Repo: existsByName(request.name)
Service->>Service: createSaveUser(request)
Service->>Repo: save(user)
Service->>Service: createUserTokens(user.email)
Service->>Token: createAccessToken(user.email)
Service->>Token: createRefreshToken(user.email)
Service->>Refresh: save(refreshToken)
Service-->>Controller: UserResponseDTO(user, accessToken)
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 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 (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
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (1)
src/test/java/com/Alchive/backend/controller/UserControllerTest.java (1)
1-45: 🛠️ Refactor suggestion테스트 메서드 이름과 실제 동작이 일치하지 않습니다.
테스트 메서드 이름과 기대 동작 사이에 불일치가 있습니다:
isDuplicateUsernameSuccess는 중복된 유저네임을 테스트하는데 "성공"이라고 명명되었습니다isDuplicateUsernameFail는 중복되지 않은 유저네임을 테스트하는데 "실패"라고 명명되었습니다이는 직관에 반하여 혼란을 줄 수 있습니다.
메서드 이름을 다음과 같이 변경하세요:
-@DisplayName("UserController 유저네임 중복 - 성공") +@DisplayName("UserController 유저네임 중복 확인 - 중복된 경우") @Test -public void isDuplicateUsernameSuccess() { +public void isDuplicateUsername_WhenDuplicated() { when(userService.isDuplicatedUsername("testNameUnique")).thenReturn(true); ResponseEntity<ResultResponse> result = sut.isDuplicateUsername("testNameUnique"); Assertions.assertEquals(true, result.getBody().getData()); } -@DisplayName("UserController 유저네임 중복 - 실패") +@DisplayName("UserController 유저네임 중복 확인 - 중복되지 않은 경우") @Test -public void isDuplicateUsernameFail() { +public void isDuplicateUsername_WhenNotDuplicated() { when(userService.isDuplicatedUsername("testNameDuplicated")).thenReturn(false); ResponseEntity<ResultResponse> result = sut.isDuplicateUsername("testNameDuplicated"); Assertions.assertEquals(false, result.getBody().getData()); }
🧹 Nitpick comments (2)
src/test/java/com/Alchive/backend/controller/UserControllerTest.java (1)
24-25: 빈 setUp 메서드는 필요한가요?현재
setUp메서드가 비어 있습니다. 필요하지 않다면 제거하는 것이 좋습니다.src/test/java/com/Alchive/backend/service/UserServiceTest.java (1)
81-92: 유저 정보 수정 테스트가 필요한 내용을 검증합니다.사용자 세부 정보 업데이트 테스트가 적절히 구현되었습니다. 하지만 다른 필드도 업데이트할 수 있다면 추가 검증이 필요할 수 있습니다.
다른 업데이트 가능한 필드(예: 프로필 이미지, 비밀번호 등)가 있다면 추가 테스트 케이스를 작성하는 것을 고려해보세요. 또한 업데이트 실패 케이스(예: 사용자를 찾을 수 없는 경우)에 대한 테스트도 유용할 수 있습니다.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
src/main/java/com/Alchive/backend/controller/UserController.java(1 hunks)src/main/java/com/Alchive/backend/dto/response/UserResponseDTO.java(1 hunks)src/main/java/com/Alchive/backend/service/UserService.java(1 hunks)src/test/java/com/Alchive/backend/controller/UserControllerTest.java(1 hunks)src/test/java/com/Alchive/backend/service/UserServiceTest.java(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (2)
src/test/java/com/Alchive/backend/controller/UserControllerTest.java (1)
src/test/java/com/Alchive/backend/service/UserServiceTest.java (1)
ExtendWith(27-93)
src/test/java/com/Alchive/backend/service/UserServiceTest.java (1)
src/test/java/com/Alchive/backend/controller/UserControllerTest.java (1)
ExtendWith(17-44)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
🔇 Additional comments (12)
src/main/java/com/Alchive/backend/dto/response/UserResponseDTO.java (1)
16-19: 코드 스타일 개선이 적용되었습니다.대입 연산자 주변에 공백을 추가하여 가독성이 향상되었습니다.
src/main/java/com/Alchive/backend/controller/UserController.java (1)
37-37: 컨트롤러 로직이 적절하게 단순화되었습니다.이전 코드에서는 조건부 로직이 있었을 것으로 추정되는데, 이제 서비스 계층에 중복 검사 로직을 위임하고 컨트롤러는 결과만 반환하는 형태로 개선되었습니다. 이는 단일 책임 원칙(SRP)에 더 잘 부합합니다.
src/main/java/com/Alchive/backend/service/UserService.java (5)
27-37: 메서드 분리를 통한 가독성 및 재사용성 향상
createUser메서드가 더 작고 집중된 메서드들로 잘 분리되었습니다. 이는 단일 책임 원칙(SRP)을 따르며, 코드의 가독성과 테스트 용이성을 향상시킵니다.
39-46: 명확한 책임 분리이메일과 사용자명 중복 검사를 별도의 메서드로 분리하여 코드 가독성이 향상되었습니다. 예외 처리도 명확하게 이루어지고 있습니다.
48-54: 중복 검사 메서드의 적절한 분리이메일과 사용자명 중복 검사를 별도의 메서드로 분리하고, 사용자명 중복 검사 메서드를 public으로 노출한 것은 좋은 결정입니다. 이를 통해 컨트롤러에서 직접 호출할 수 있게 되었습니다.
56-59: 사용자 생성 및 저장 책임 분리사용자 생성과 저장 로직을 별도의 메서드로 분리하여 코드 가독성이 향상되었습니다.
61-66: 토큰 생성 로직의 적절한 분리토큰 생성 로직을 별도의 메서드로 분리하여 재사용성과 가독성이 향상되었습니다. 액세스 토큰과 리프레시 토큰을 함께 처리하는 메서드가 잘 구성되었습니다.
src/test/java/com/Alchive/backend/service/UserServiceTest.java (5)
1-37: 테스트 클래스 기본 구성이 개선되었습니다.클래스 구조가 더 명확해졌고 Mockito 확장 사용과 필요한 의존성 모킹이 잘 설정되었습니다. 특히 이전 코드에서
TokenService와HttpServletRequest모킹 대신JwtTokenProvider와RefreshTokenService를 모킹하는 방식으로 변경된 것이 서비스 계층 리팩토링에 적절히 대응하고 있습니다.
38-43: 테스트 데이터 설정이 간결해졌습니다.공통 테스트 데이터를 멤버 변수로 정의하여 코드 중복을 줄이고 가독성을 높였습니다. 특히 User 객체를 직접 생성하는 방식으로 단순화한 점이 좋습니다.
44-60: 유저 생성 성공 테스트가 잘 구현되었습니다.Service 계층 리팩토링에 맞춰 토큰 생성과 중복 체크, 유저 저장 등의 모든 로직을 포함하고 있습니다. 특히 refreshToken 저장 로직 테스트를 위한
doNothing()사용이 적절합니다.
62-69: 이메일 중복 예외 처리 테스트가 간결하게 작성되었습니다.
UserEmailExistException예외 발생을 검증하는 테스트가 잘 구현되었습니다.
71-79: 유저네임 중복 예외 처리 테스트가 명확하게 작성되었습니다.
UserNameExistException예외 발생을 검증하는 테스트가 잘 구현되었습니다.
Summary
Description
Screenshot
Test Checklist
Summary by CodeRabbit