Skip to content

Conversation

@jj0526
Copy link
Collaborator

@jj0526 jj0526 commented Nov 11, 2025

📌 PR 내용

  • 게시판 및 댓글 테스트 코드 작성

🔍 PR 세부사항

  • Post와 Notice의 공통되는 부분은 한번만 작성하였습니다
  • Repository 및 Service는 다음 PR에서 작성하겠습니다

📸 관련 스크린샷

x

📝 주의사항

x

✅ 체크리스트

  • 리뷰어 설정
  • Assignee 설정
  • Label 설정
  • 제목 양식 맞췄나요? (ex. [WTH-01] PR 템플릿 수정)
  • 변경 사항에 대한 테스트

Summary by CodeRabbit

  • Tests

    • 테스트 인프라 개선: 모의 객체 주입 방식 통일 및 테스트 명명·표시 정비
    • 신규 단위테스트 추가: 공지 업데이트(파일 교체 포함), 게시물 저장/조회, 공지 댓글 생성·권한 검증 등 시나리오 확대
    • 검증 강화: 파일 저장/삭제 흐름 및 서비스 호출 검증 추가
  • Fixtures

    • 테스트 픽스처 정비: 기존 픽스처 대체·삭제 및 Notice/Post/Comment/File/User 등 여러 픽스처 추가

참고: 내부 테스트 개선으로 사용자 기능에는 영향 없습니다.

✏️ Tip: You can customize this high-level summary in your review settings.

jj0526 added 22 commits November 5, 2025 16:39
@jj0526 jj0526 requested review from hyxklee and seokjun01 November 11, 2025 10:57
@jj0526 jj0526 self-assigned this Nov 11, 2025
@jj0526 jj0526 added the test label Nov 11, 2025
@coderabbitai
Copy link

coderabbitai bot commented Nov 11, 2025

Walkthrough

테스트 리팩터링과 확장: NoticeUsecase 테스트를 @InjectMocks 기반으로 재구성하고 NoticeFixtureNoticeTestFixture로 교체했으며, Post/Comment/File/User 관련 신규 테스트 클래스와 여러 테스트 픽스처를 추가했습니다.

Changes

Cohort / File(s) 요약
Notice 테스트 리팩터링
src/test/java/leets/weeth/domain/board/application/usecase/NoticeUsecaseImplTest.java, src/test/java/leets/weeth/domain/board/domain/repository/NoticeRepositoryTest.java
NoticeUsecaseImplTest@InjectMocks 도입 및 다수의 파일 관련 서비스·매퍼(FileSaveService, FileGetService, FileDeleteService, NoticeMapper, FileMapper 등) 목(Mock) 추가. Repository 테스트의 픽스처 참조를 NoticeTestFixture로 교체
Notice 픽스처 추가/삭제
src/test/java/leets/weeth/domain/board/domain/test/fixture/NoticeFixture.java (삭제), src/test/java/leets/weeth/domain/board/test/fixture/NoticeTestFixture.java (추가)
기존 NoticeFixture 삭제 및 다양한 오버로드 정적 팩토리를 제공하는 NoticeTestFixture 신규 추가
Post 테스트 및 픽스처 추가
src/test/java/leets/weeth/domain/board/application/usecase/PostUseCaseImplTest.java, src/test/java/leets/weeth/domain/board/test/fixture/PostTestFixture.java
게시글 저장/조회/권한/페이징/파일 존재 여부 검증하는 PostUseCaseImplTest 추가 및 Post/응답 DTO 생성용 PostTestFixture 추가
Comment 테스트 및 픽스처 추가
src/test/java/leets/weeth/domain/comment/application/usecase/NoticeCommentUsecaseImplTest.java, src/test/java/leets/weeth/domain/comment/test/fixture/CommentTestFixture.java
루트 및 자식 댓글 생성, 권한 검증 테스트 추가 및 Comment 엔티티 생성 헬퍼 추가
File 픽스처 추가
src/test/java/leets/weeth/domain/file/test/fixture/FileTestFixture.java
File 엔티티 생성용 정적 팩토리 메서드(오버로드) 추가
User 픽스처 확장
src/test/java/leets/weeth/domain/user/test/fixture/UserTestFixture.java
ADMIN 역할 사용자 생성 헬퍼 createAdmin(Long id) 추가

Sequence Diagram(s)

(생성 조건에 부합하지 않아 생략됨)

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

  • 집중 검토 권장 항목:
    • NoticeUsecaseImplTest: @InjectMocks 전환으로 Mockito 초기화/의존성 누락 여부 및 파일 삭제·저장 호출·순서 검증
    • PostUseCaseImplTest: 권한 검사(예외 경로) 및 페이징/정렬 스텁의 적절성
    • 신규 픽스처들: 엔티티 필드(id, user, 연관관계) 초기화 일관성 및 테스트 데이터 독립성

Possibly related PRs

Suggested reviewers

  • huncozyboy
  • hyxklee
  • seokjun01

🐰 픽스처 갈아끼우고 테스트 줄 맞췄네
파일 지우고 새로 저장하는 춤을 췄네
목(Mock)들 모여서 손뼉 치며 검증하고
토끼는 깡충, 빛나는 당근 하나로 축하하네 🥕✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed 제목은 PR의 주요 변경사항을 명확하게 설명하며, 'WTH-58 게시판 및 댓글 테스트 코드 작성'은 게시판 및 댓글 관련 테스트 코드 작성이라는 핵심 목표를 직관적으로 전달합니다.
Description check ✅ Passed PR 설명은 필수 섹션을 모두 포함하며, PR 내용과 세부사항을 제시하고 체크리스트를 완료했습니다. 다만 스크린샷과 주의사항은 'x'로 표기되었으나 이는 해당 항목이 필요하지 않음을 명확히 한 것입니다.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch WTH-58-Weeth-게시판-및-댓글-테스트-코드-작성

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 561e00f and 08eff0c.

📒 Files selected for processing (1)
  • src/test/java/leets/weeth/domain/board/application/usecase/PostUseCaseImplTest.java (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • src/test/java/leets/weeth/domain/board/application/usecase/PostUseCaseImplTest.java

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🧹 Nitpick comments (2)
src/test/java/leets/weeth/domain/board/test/fixture/PostTestFixture.java (1)

26-38: Category 파라미터를 실제로 사용하도록 보완해주세요.
메서드 시그니처로 Category category를 받고 있지만 내부에서는 언제나 Category.Education으로 고정되어 호출자가 어떤 값을 넘기든 무시됩니다. 테스트 픽스처라도 시그니처와 구현이 불일치하면 추후 재사용 시 혼동을 줄 수 있으니 전달받은 값을 그대로 사용하도록 조정하는 편이 안전합니다.

-                .category(Category.Education)
+                .category(category)
src/test/java/leets/weeth/domain/board/application/usecase/PostUseCaseImplTest.java (1)

146-147: 테스트 스텁에서 실제 SUT 메서드를 호출하지 않도록 정리해주세요.
given(... postUseCase.checkFileExistsByPost(...))/verify(... postUseCase.checkFileExistsByPost(...))처럼 스텁·검증 시점에 실제 구현을 호출하면, 설정 단계에서 fileGetService 모의 객체가 findAllByPost를 두 번 이상 호출하게 되어 테스트가 내부 구현에 강하게 결합됩니다. 구현이 null을 반환하거나 호출 횟수를 검증하게 되는 순간 테스트가 쉽게 깨질 수 있으니, 먼저 fileGetService에 대한 반환 값을 명시적으로 스텁한 뒤 단순한 불리언 리터럴이나 지역 변수로 매퍼 인자를 넘기는 쪽이 더 견고합니다.

given(fileGetService.findAllByPost(post2.getId())).willReturn(List.of());
boolean fileExists = false;
given(mapper.toAll(post2, fileExists)).willReturn(response2);

이런 식으로 SUT 호출을 분리하면 검증 구문에서도 동일한 fileExists 값을 재사용할 수 있습니다.

Also applies to: 194-195, 209-210

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 28951b4 and 81df671.

📒 Files selected for processing (10)
  • src/test/java/leets/weeth/domain/board/application/usecase/NoticeUsecaseImplTest.java (5 hunks)
  • src/test/java/leets/weeth/domain/board/application/usecase/PostUseCaseImplTest.java (1 hunks)
  • src/test/java/leets/weeth/domain/board/domain/repository/NoticeRepositoryTest.java (3 hunks)
  • src/test/java/leets/weeth/domain/board/domain/test/fixture/NoticeFixture.java (0 hunks)
  • src/test/java/leets/weeth/domain/board/test/fixture/NoticeTestFixture.java (1 hunks)
  • src/test/java/leets/weeth/domain/board/test/fixture/PostTestFixture.java (1 hunks)
  • src/test/java/leets/weeth/domain/comment/application/usecase/NoticeCommentUsecaseImplTest.java (1 hunks)
  • src/test/java/leets/weeth/domain/comment/test/fixture/CommentTestFixture.java (1 hunks)
  • src/test/java/leets/weeth/domain/file/test/fixture/FileTestFixture.java (1 hunks)
  • src/test/java/leets/weeth/domain/user/test/fixture/UserTestFixture.java (2 hunks)
💤 Files with no reviewable changes (1)
  • src/test/java/leets/weeth/domain/board/domain/test/fixture/NoticeFixture.java
🧰 Additional context used
🧬 Code graph analysis (6)
src/test/java/leets/weeth/domain/board/application/usecase/PostUseCaseImplTest.java (6)
src/main/java/leets/weeth/domain/board/application/dto/PostDTO.java (1)
  • PostDTO (19-131)
src/main/java/leets/weeth/domain/board/application/exception/CategoryAccessDeniedException.java (1)
  • CategoryAccessDeniedException (5-9)
src/test/java/leets/weeth/domain/board/test/fixture/PostTestFixture.java (1)
  • PostTestFixture (14-75)
src/test/java/leets/weeth/domain/file/test/fixture/FileTestFixture.java (1)
  • FileTestFixture (6-23)
src/test/java/leets/weeth/domain/user/test/fixture/CardinalTestFixture.java (1)
  • CardinalTestFixture (6-45)
src/test/java/leets/weeth/domain/user/test/fixture/UserTestFixture.java (1)
  • UserTestFixture (7-86)
src/test/java/leets/weeth/domain/comment/application/usecase/NoticeCommentUsecaseImplTest.java (5)
src/test/java/leets/weeth/domain/board/test/fixture/NoticeTestFixture.java (1)
  • NoticeTestFixture (8-48)
src/main/java/leets/weeth/domain/comment/application/dto/CommentDTO.java (1)
  • CommentDTO (16-43)
src/test/java/leets/weeth/domain/comment/test/fixture/CommentTestFixture.java (1)
  • CommentTestFixture (9-20)
src/main/java/leets/weeth/domain/user/application/exception/UserNotMatchException.java (1)
  • UserNotMatchException (5-7)
src/test/java/leets/weeth/domain/user/test/fixture/UserTestFixture.java (1)
  • UserTestFixture (7-86)
src/test/java/leets/weeth/domain/board/test/fixture/NoticeTestFixture.java (1)
src/test/java/leets/weeth/domain/board/domain/test/fixture/NoticeFixture.java (1)
  • NoticeFixture (6-23)
src/test/java/leets/weeth/domain/board/application/usecase/NoticeUsecaseImplTest.java (3)
src/test/java/leets/weeth/domain/board/test/fixture/NoticeTestFixture.java (1)
  • NoticeTestFixture (8-48)
src/test/java/leets/weeth/domain/file/test/fixture/FileTestFixture.java (1)
  • FileTestFixture (6-23)
src/test/java/leets/weeth/domain/user/test/fixture/UserTestFixture.java (1)
  • UserTestFixture (7-86)
src/test/java/leets/weeth/domain/board/test/fixture/PostTestFixture.java (1)
src/main/java/leets/weeth/domain/board/application/dto/PostDTO.java (1)
  • PostDTO (19-131)
src/test/java/leets/weeth/domain/board/domain/repository/NoticeRepositoryTest.java (1)
src/test/java/leets/weeth/domain/board/test/fixture/NoticeTestFixture.java (1)
  • NoticeTestFixture (8-48)
⏰ 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: build

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (1)
src/test/java/leets/weeth/domain/user/test/fixture/UserTestFixture.java (1)

77-85: 일관성을 위해 파라미터 없는 버전 추가 고려

다른 사용자 생성 메서드들(createActiveUser1, createWaitingUser1 등)은 모두 파라미터 없는 버전과 ID 파라미터 버전을 함께 제공합니다. createAdmin()에도 파라미터 없는 오버로드 메서드를 추가하면 픽스처의 일관성을 유지할 수 있습니다.

다음과 같이 파라미터 없는 버전을 추가할 수 있습니다:

+    public static User createAdmin() {
+        return User.builder()
+                .name("적순")
+                .email("[email protected]")
+                .status(Status.ACTIVE)
+                .role(Role.ADMIN)
+                .build();
+    }
+
     public static User createAdmin(Long id) {
         return User.builder()
                 .id(id)
                 .name("적순")
                 .email("[email protected]")
                 .status(Status.ACTIVE)
                 .role(Role.ADMIN)
                 .build();
     }
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 81df671 and f0432d7.

📒 Files selected for processing (1)
  • src/test/java/leets/weeth/domain/user/test/fixture/UserTestFixture.java (2 hunks)
🔇 Additional comments (1)
src/test/java/leets/weeth/domain/user/test/fixture/UserTestFixture.java (1)

77-85: 이전 리뷰 이슈가 해결되었습니다!

ID 설정이 올바르게 추가되었습니다 (Line 79). 이전 리뷰에서 지적된 .id(id) 누락 문제가 해결되어 이제 메서드가 의도대로 동작합니다.

Long noticeId = 1L;
Long userId = 1L;

User user = UserTestFixture.createActiveUser1(userId);
Copy link
Collaborator

Choose a reason for hiding this comment

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

유저 Fixture 가져와서 사용해주셨네요 ! 굳👍🏻

assertThat(notice.getTitle()).isEqualTo(dto.title());
assertThat(notice.getContent()).isEqualTo(dto.content());
}
}
Copy link
Collaborator

@seokjun01 seokjun01 Nov 11, 2025

Choose a reason for hiding this comment

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

given 단계에서 중복되는 객체설정은 (user, notice) , setUp() 메소드로 뺴놓아도 좋을 것 같아용
지금은 두 번 밖에 없지만! 추후에 검증이 추가된다면 고려해봐도 좋을 것 같습니다

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

좋은 피드백 감사합니다! 하지만 이 테스트 클래스엔는 setUp()으로 공통 초기화 하는 것이 메소드마다 여러개의 Notice가 필요한지 단일 Notice가 필요한지가 달라서 사용하기에는 부적합한거같습니다!

Comment comment = CommentTestFixture.createComment(commentId, dto.content(), user, notice);

given(userGetService.find(user2.getId())).willReturn(user2);
given(noticeFindService.find(notice.getId())).willReturn(notice);
Copy link
Collaborator

Choose a reason for hiding this comment

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

이 부분은 댓글을 쓴사람과 관련이 있는 부분이라 noticeFindService가 필요한가요 ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

네! 맞습니다

Copy link
Collaborator

@seokjun01 seokjun01 left a comment

Choose a reason for hiding this comment

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

고생하셨습니다! 전반적으로 코드가 짜임새가 좋으나 약간 길어서 😢
불필요한 verify는 제거하고, 중복을 줄이면 더 좋은 코드가 될 것 같습니다! 코멘트 확인해주세요 ~😄👍🏻

Copy link
Collaborator

@hyxklee hyxklee left a comment

Choose a reason for hiding this comment

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

고생하셧습니당!

// then
assertThat(response).isEqualTo(expectedResponse);

verify(noticeFindService).find(noticeId);
Copy link
Collaborator

Choose a reason for hiding this comment

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

호출 여부까지는 전부 검증해줄 필요는 없을 것 같아욤

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Nitpick comments (1)
src/test/java/leets/weeth/domain/board/application/usecase/NoticeUsecaseImplTest.java (1)

193-230: 과도한 검증 호출을 줄이는 것을 고려해보세요.

테스트가 잘 작성되었지만, 224-229번 라인의 모든 메서드 호출을 검증하는 것은 과도할 수 있습니다. 이전 리뷰에서도 "호출 여부까지는 전부 검증해줄 필요는 없을 것 같아욤"이라는 피드백이 있었습니다.

핵심 동작(파일 삭제, 저장, 업데이트)만 검증하고 나머지는 생략하는 것을 권장합니다. 예를 들어:

-        verify(noticeFindService).find(noticeId);
-        verify(fileGetService).findAllByNotice(noticeId);
         verify(fileDeleteService).delete(oldFiles);
-        verify(fileMapper).toFileList(dto.files(), notice);
         verify(fileSaveService).save(newFiles);
         verify(noticeUpdateService).update(notice, dto);
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f0432d7 and 561e00f.

📒 Files selected for processing (3)
  • src/test/java/leets/weeth/domain/board/application/usecase/NoticeUsecaseImplTest.java (5 hunks)
  • src/test/java/leets/weeth/domain/board/application/usecase/PostUseCaseImplTest.java (1 hunks)
  • src/test/java/leets/weeth/domain/comment/application/usecase/NoticeCommentUsecaseImplTest.java (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • src/test/java/leets/weeth/domain/comment/application/usecase/NoticeCommentUsecaseImplTest.java
🧰 Additional context used
🧬 Code graph analysis (1)
src/test/java/leets/weeth/domain/board/application/usecase/NoticeUsecaseImplTest.java (3)
src/test/java/leets/weeth/domain/board/test/fixture/NoticeTestFixture.java (1)
  • NoticeTestFixture (8-48)
src/test/java/leets/weeth/domain/file/test/fixture/FileTestFixture.java (1)
  • FileTestFixture (6-23)
src/test/java/leets/weeth/domain/user/test/fixture/UserTestFixture.java (1)
  • UserTestFixture (7-87)
⏰ 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: build
🔇 Additional comments (5)
src/test/java/leets/weeth/domain/board/application/usecase/NoticeUsecaseImplTest.java (2)

39-49: 목 주입 방식 개선이 잘 적용되었습니다.

@InjectMocks@Mock 어노테이션을 사용하여 테스트 코드가 더 명확하고 간결해졌습니다.


233-247: 엔티티 메서드 테스트가 적절합니다.

Notice 엔티티의 update() 메서드를 직접 테스트하여 제목과 내용이 정상적으로 변경되는지 검증하고 있습니다.

src/test/java/leets/weeth/domain/board/application/usecase/PostUseCaseImplTest.java (3)

67-94: 교육 게시글 저장 테스트가 잘 작성되었습니다.

given-when-then 구조가 명확하고, 필요한 검증이 적절하게 이루어지고 있습니다.


232-263: 권한 검증 로직이 잘 테스트되었습니다.

사용자가 해당 기수에 속하지 않을 때 빈 리스트를 반환하는 것을 확인하고, never()를 사용하여 불필요한 메서드 호출이 없음을 검증하고 있습니다.


265-279: 파일 존재 여부 확인 테스트가 명확합니다.

간단하고 명확하게 파일 존재 여부를 검증하고 있습니다.

@jj0526 jj0526 merged commit 489bd4d into develop Nov 30, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants