[Feat] 챌린지 중도 참여 로직 구현 및 테스트 코드 수정 #185
Conversation
- 챌린지가 진행 중(ONGOING)이더라도 정원이 남았다면 참여할 수 있도록 검증 로직 수정 - 미참여자가 진행 중인 챌린지 조회 시 '참가하기' 버튼이 노출되도록 버튼 상태 결정 로직 개선 - 챌린지 종료(FINISHED) 상태가 아닌 경우 모든 모집 단계에서 참여 가능하도록 완화
- ChallengeServiceInfoTest에 상황 9(진행 중인 챌린지 + 자리 있음 -> JOIN) 케이스 추가 - 상태가 ONGOING일 때도 참가하기 버튼이 정상 반환되는지 검증
- LocalTime.now() 기반의 상대적 시간 계산을 고정 시간 및 MIN/MAX 상수로 교체 - 자정 전후 테스트 실행 시 발생하던 시간 역전(start > end) 버그 해결 - 테스트 데이터 생성 시 비즈니스 규칙(인증 종료 시간 > 시작 시간)을 준수하도록 수정
📝 WalkthroughWalkthrough챌린지 참가 로직이 완화되었습니다. 가입 요청 검증은 완료 상태만 차단하도록 변경되었으며, 버튼 상태 결정에서 비참가자의 상태별 조건 제한이 제거되었습니다. 테스트는 시간 기반 불안정성을 해결하기 위해 고정된 시간 범위를 사용하도록 수정되었고, 진행 중인 챌린지 참가 시나리오가 추가되었습니다. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
PoemPre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ 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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
src/test/java/com/hrr/backend/domain/challenge/service/ChallengeServiceInfoTest.java (3)
66-66: 시간 의존성 버그 수정 완료! 🎉
LocalTime.now()기반의 동적 시간 계산을 고정된 시간 범위로 교체하여 자정 전후 발생하던 테스트 불안정성을 해결했습니다. 전략이 명확합니다:
- Lines 66, 95:
9:00-18:00- 실제 인증 시간대를 시뮬레이션하는 현실적인 범위- Line 121:
00:00-00:01- 현재 시간이 범위 밖임을 보장하는 좁은 창- Lines 145, 172:
MIN-MAX- 시간이 제한 요소가 되지 않아야 하는 테스트Line 121 개선 제안
00:00-00:01 범위는 극히 드물지만 테스트가 정확히 자정에 실행될 경우 범위 내에 포함될 수 있습니다. 더 안전한 방법은 과거 시간대를 사용하는 것입니다:
- setVerificationTime(challenge, LocalTime.of(0, 0), LocalTime.of(0, 1)); + setVerificationTime(challenge, LocalTime.of(2, 0), LocalTime.of(3, 0));또는
LocalTime.now().isBefore(start)를 보장하는 미래 시간을 사용할 수도 있습니다.참고: Java 시간 API의 불변성과 테스트 안정성에 대해 더 알고 싶다면 Baeldung의 Testing Date and Time 가이드를 추천합니다.
Also applies to: 95-95, 121-121, 145-145, 172-172
260-260: 시간 의존성이 남아있습니다이 테스트는
FINISHED상태를 검증하므로 시간대가 실제 로직에 영향을 주지 않습니다. 하지만LocalTime.now()를 사용하면 다른 테스트에서 제거한 시간 의존성이 다시 도입됩니다. 일관성을 위해 고정 시간을 사용하는 것이 좋습니다.제안하는 수정
- setVerificationTime(challenge, LocalTime.now().minusHours(1), LocalTime.now().plusHours(1)); + setVerificationTime(challenge, LocalTime.of(9, 0), LocalTime.of(18, 0));또는 더 명시적으로:
- setVerificationTime(challenge, LocalTime.now().minusHours(1), LocalTime.now().plusHours(1)); + setVerificationTime(challenge, LocalTime.MIN, LocalTime.MAX);
275-298: 중도 참여 시나리오 테스트 추가 완료! ✅
ONGOING상태의 챌린지에 자리가 있을 때 미참여자가JOIN버튼을 볼 수 있는지 검증하는 테스트가 추가되었습니다. PR 목표인 중도 참여 로직의 핵심 시나리오를 커버하고 있습니다.테스트 커버리지를 더 강화하려면 다음 시나리오를 추가로 검증하는 것을 권장합니다:
- ONGOING + 만석 케이스: 진행 중이지만 정원이 찬 경우
WAITLIST반환 확인- 실제 참여 검증:
joinChallenge메서드가ONGOING상태에서 정상 동작하는지 통합 테스트 추가추가 테스트 예시
@Test @DisplayName("상황 10: 미참여자 + 진행중(ONGOING) + 만석 -> WAITLIST") void guest_ongoing_full_returns_WAITLIST() { // Given Long challengeId = 1L; User user = mock(User.class); Challenge challenge = mock(Challenge.class); // 조건: 진행 중이지만 만석 setChallengeStatus(challenge, ChallengeStatus.ONGOING, 10, 10); setRoundDate(challenge, LocalDate.now().minusDays(5)); // Mocking mockFetchingChallenge(challengeId, challenge); mockParticipant(user, challenge, false); mockConverter(ActionButtonStatus.WAITLIST); // When ChallengeResponseDto.HeaderInfoDto result = challengeService.getChallengeHeaderInfo(challengeId, user); // Then assertThat(result.getActionButtonStatus()).isEqualTo(ActionButtonStatus.WAITLIST); }
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/main/java/com/hrr/backend/domain/challenge/service/ChallengeServiceImpl.javasrc/test/java/com/hrr/backend/domain/challenge/service/ChallengeServiceInfoTest.java
🔇 Additional comments (2)
src/main/java/com/hrr/backend/domain/challenge/service/ChallengeServiceImpl.java (2)
762-763: 버튼 로직 단순화 굿! 🎯미참여자에게 상태별 제한 없이 자리가 있으면 무조건
JOIN을 반환하도록 개선되었습니다. 이는 Lines 642-643의 검증 로직 완화와 일관성을 유지하며, 코드의 복잡도를 낮춰 유지보수성을 높였습니다.다만,
UPCOMING상태(챌린지 시작 전)에서도JOIN버튼이 노출되는데, 이것이 의도된 UX인지 확인이 필요합니다. 일부 서비스에서는 시작 전 챌린지에 "예약하기" 등 다른 문구를 사용하기도 합니다. 기획 의도와 일치하는지 체크해주세요.
642-645: 중도 참여 시 현재 라운드만 기록하는 것이 설계 의도인지 확인 필요
createRoundRecordOrFail(line 458)에서challenge.getCurrentRound()기준으로만 RoundRecord를 생성하고 있습니다. 진행 중인 챌린지에 참여하는 경우도 현재 라운드 기록만 생성되며, 지난 라운드에 대한 기록은 생성되지 않습니다.이것이 의도된 설계라면 (중도 참여자는 현재 라운드부터만 추적), 그 의도를 명시하는 주석을 추가하면 향후 유지보수 시 혼동을 막을 수 있습니다. 예를 들어:
// 중도 참여자는 현재 라운드부터만 참여 기록을 시작합니다. // 과거 라운드 이력은 API 응답의 remainDays 기반으로 사용자에게 표시됩니다.지만 만약 중도 참여자도 지난 라운드를 추적해야 한다면, 모든 이전 라운드에 대해 RoundRecord를 생성하는 로직이 필요합니다.
yc3697
left a comment
yc3697
left a comment
There was a problem hiding this comment.
거 참 코드래빗 리뷰 안 남는 거 부럽네,,, 수고하였어요,,,
ㅎㅎ 감삼다 |
#️⃣ 연관된 이슈
✨ 작업 내용 (Summary)
챌린지의 중도 참여 로직을 도입하였습니다. 이때 챌린지 연장 알림이 보내진 후에 참여하는 챌린저들을 위해 라운드가 n일 남았다는 정보를 제공해야 하는데, 이는 챌린지 상단 정보 조회 API의
remainDays를 사용합니다.또한 시간 의존성으로 인해 발생하던 테스트 버그(자정 전후로 테스트 실행 시 LocalTime 계산 오류로 빌드 실패)를 해결하여 빌드 안정성을 확보했습니다.
✅ 변경 사항 체크리스트
🧪 테스트 결과
📸 스크린샷
💬 리뷰 요구사항
테스트 안정성:
LocalTime.MIN/MAX를 사용해 시간 의존성을 제거한 방식📎 참고 자료
Summary by CodeRabbit
릴리스 노트
새로운 기능
버그 수정
테스트
✏️ Tip: You can customize this high-level summary in your review settings.