refactor: 유저 관련 통합 테스트 데이터 fixture 메서드로 변경 #319
Conversation
Walkthrough
Note ⚡️ AI Code Reviews for VS Code, Cursor, WindsurfCodeRabbit now has a plugin for VS Code, Cursor and Windsurf. This brings AI code reviews directly in the code editor. Each commit is reviewed immediately, finding bugs before the PR is raised. Seamless context handoff to your AI code agent ensures that you can easily incorporate review feedback. Note ⚡️ Faster reviews with cachingCodeRabbit now supports caching for code and dependencies, helping speed up reviews. This means quicker feedback, reduced wait times, and a smoother review experience overall. Cached data is encrypted and stored securely. This feature will be automatically enabled for all accounts on May 16th. To opt out, configure 📜 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
🪧 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 (
|
Docstrings generation was requested by @Gyuhyeok99. * #319 (comment) The following files were modified: * `src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixture.java` * `src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixtureBuilder.java`
|
Note Generated docstrings for this pull request at #320 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
src/test/java/com/example/solidconnection/concurrency/PostLikeCountConcurrencyTest.java (1)
93-95: 개선 제안: 임시 사용자 생성에도 픽스처 활용 검토동시성 테스트에서 여러 임시 사용자를 생성할 때도 SiteUserFixture를 활용할 수 있습니다. 현재는 직접 createSiteUserByEmail 메소드와 repository를 사용하고 있지만, 픽스처에 이메일을 파라미터로 받는 메소드를 추가하여 일관된 방식으로 사용자를 생성할 수 있습니다.
- SiteUser tmpSiteUser = siteUserRepository.save(createSiteUserByEmail(email)); + SiteUser tmpSiteUser = siteUserFixture.테스트_유저(email);src/test/java/com/example/solidconnection/siteuser/repository/SiteUserRepositoryTest.java (1)
14-17: 테스트 설정 방식에 대한 논의가 필요합니다.주석으로 남겨진 내용을 보면 테스트 설정 방식에 대한 고민이 있는 것 같습니다. 현재는
@TestContainerSpringBootTest를 사용하고 있지만,@TestContainerDataJpaTest + @Import조합과의 비교 검토가 필요하다고 되어 있습니다.
@TestContainerDataJpaTest
- JPA 관련 컴포넌트만 로드하여 더 가벼운 테스트 실행
- 트랜잭션 관리 자동화
@TestContainerSpringBootTest
- 전체 애플리케이션 컨텍스트 로드
- 통합 테스트에 적합하지만 무거움
현재 이 테스트는 레포지토리 테스트이므로
@TestContainerDataJpaTest + @Import(SiteUserFixture.class)방식이 더 적합할 수 있습니다. 더 가벼운 테스트 실행과 함께 필요한 컴포넌트만 추가할 수 있기 때문입니다.src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixture.java (1)
1-93: 종합적인 개선 제안
메서드 문서화:
- 각 메서드에 JavaDoc 주석을 추가하여 사용 목적과 반환값을 명확히 설명하면 좋겠습니다.
유연성 향상:
- 현재는
MENTEE와ADMIN역할만 생성 가능합니다.- 역할을 매개변수로 받는 메서드를 추가하면 더 다양한 테스트 시나리오에 대응할 수 있을 것입니다.
에러 처리 및 유효성 검사:
- 입력 매개변수에 대한 기본적인 유효성 검사를 추가하면 좋겠습니다.
국제화 고려:
- 한국어 메서드 이름은 한국어 사용자에게 직관적이지만, 필요시 영어 버전의 메서드도 함께 제공하는 것을 고려해보세요.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (21)
src/test/java/com/example/solidconnection/admin/service/AdminGpaScoreServiceTest.java(2 hunks)src/test/java/com/example/solidconnection/admin/service/AdminLanguageTestScoreServiceTest.java(2 hunks)src/test/java/com/example/solidconnection/auth/service/AuthServiceTest.java(3 hunks)src/test/java/com/example/solidconnection/auth/service/EmailSignInServiceTest.java(3 hunks)src/test/java/com/example/solidconnection/auth/service/SignInServiceTest.java(3 hunks)src/test/java/com/example/solidconnection/concurrency/PostLikeCountConcurrencyTest.java(2 hunks)src/test/java/com/example/solidconnection/concurrency/PostViewCountConcurrencyTest.java(5 hunks)src/test/java/com/example/solidconnection/concurrency/ThunderingHerdTest.java(3 hunks)src/test/java/com/example/solidconnection/custom/resolver/AuthorizedUserResolverTest.java(4 hunks)src/test/java/com/example/solidconnection/custom/security/aspect/AdminAuthorizationAspectTest.java(3 hunks)src/test/java/com/example/solidconnection/custom/security/provider/SiteUserAuthenticationProviderTest.java(5 hunks)src/test/java/com/example/solidconnection/custom/security/userdetails/SiteUserDetailsServiceTest.java(3 hunks)src/test/java/com/example/solidconnection/custom/security/userdetails/SiteUserDetailsTest.java(2 hunks)src/test/java/com/example/solidconnection/score/service/ScoreServiceTest.java(7 hunks)src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixture.java(1 hunks)src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixtureBuilder.java(1 hunks)src/test/java/com/example/solidconnection/siteuser/repository/SiteUserRepositoryTest.java(1 hunks)src/test/java/com/example/solidconnection/siteuser/service/MyPageServiceTest.java(6 hunks)src/test/java/com/example/solidconnection/siteuser/service/SiteUserServiceTest.java(3 hunks)src/test/java/com/example/solidconnection/university/service/UniversityLikeServiceTest.java(7 hunks)src/test/java/com/example/solidconnection/university/service/UniversityRecommendServiceTest.java(6 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixtureBuilder.java (1)
src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixture.java (1)
TestComponent(10-93)
🔇 Additional comments (93)
src/test/java/com/example/solidconnection/custom/security/aspect/AdminAuthorizationAspectTest.java (3)
6-6: SiteUserFixture import 추가가 좋습니다!테스트에서 공통적으로 사용되는 SiteUser 객체를 생성하기 위한 fixture 클래스를 활용한 리팩토링이 잘 되었습니다.
26-27: DI를 통한 SiteUserFixture 주입 방식이 적절합니다.Spring 컨테이너의 의존성 주입을 활용해 fixture를 주입받는 방식으로 테스트 데이터 관리를 표준화했습니다.
32-33: 테스트 유저 생성 방식의 개선이 잘 이루어졌습니다!기존에 각 테스트 클래스마다 중복되었던 유저 생성 로직을 SiteUserFixture로 이동하여:
- 코드 중복이 제거되었습니다.
- 테스트 데이터 생성 방식이 표준화되었습니다.
- 테스트 코드의 가독성이 향상되었습니다.
- 유지보수성이 개선되었습니다.
이는 PR의 핵심 목표인 '유저 관련 통합 테스트 데이터를 fixture 메서드로 변경'을 잘 달성한 변경입니다.
Also applies to: 44-45, 55-56
src/test/java/com/example/solidconnection/custom/security/userdetails/SiteUserDetailsTest.java (3)
4-4: SiteUserFixture import 추가가 적절합니다.테스트 유저 생성을 위한 fixture 클래스 import가 잘 추가되었습니다.
20-20: SiteUserFixture 주입 방식이 일관성 있게 적용되었습니다.테스트 코드 전반에 걸쳐 동일한 방식으로 SiteUserFixture를 주입받아 일관된 패턴을 유지하고 있습니다.
25-26: 테스트 유저 생성 방식 개선이 효과적입니다.
- fixture를 통한 테스트 유저 생성으로 코드가 더 간결해졌습니다.
- 이전 직접 생성 방식보다 표준화된 접근법을 사용하고 있습니다.
- 테스트 내용에 집중할 수 있도록 설정 코드의 복잡성이 감소했습니다.
이 변경은 특히 작은 테스트 클래스에서도 일관된 패턴을 유지하는 데 도움이 됩니다.
Also applies to: 34-34
src/test/java/com/example/solidconnection/custom/security/userdetails/SiteUserDetailsServiceTest.java (4)
5-5: SiteUserFixture import 추가가 적절합니다.테스트 유저 생성을 위한 fixture 클래스 import가 잘 추가되었습니다.
28-29: DI를 통한 SiteUserFixture 주입이 일관성 있게 적용되었습니다.다른 테스트 클래스들과 동일한 방식으로 SiteUserFixture를 주입받아 프로젝트 전체의 일관성을 유지했습니다.
37-38: 테스트 유저 생성 방식이 개선되었습니다.fixture를 통한 테스트 유저 생성으로 코드가 간결해지고 테스트 내용에 집중할 수 있게 되었습니다.
78-81: 테스트 유저 수정 로직이 잘 유지되었습니다.Fixture를 사용하면서도 특수한 케이스(탈퇴한 사용자)를 테스트하기 위한 사용자 수정 로직이 적절하게 유지되었습니다. 이는 Fixture 패턴을 도입하면서도 테스트별 유연성을 잘 확보한 예입니다.
src/test/java/com/example/solidconnection/score/service/ScoreServiceTest.java (8)
18-18: SiteUserFixture import 추가가 적절합니다.테스트 유저 생성을 위한 fixture 클래스 import가 잘 추가되었습니다.
55-56: SiteUserFixture 주입 방식이 일관성 있게 적용되었습니다.다른 테스트 클래스들과 동일한 방식으로 SiteUserFixture를 주입받아 일관성을 유지했습니다.
58-63: @beforeeach를 활용한 테스트 설정이 효율적입니다.
- 테스트 실행 전 공통 설정을
@BeforeEach로 처리하여 코드 중복을 제거했습니다.- 여러 테스트에서 재사용되는 테스트 유저 객체를 클래스 필드로 선언하여 효율성을 높였습니다.
- 각 테스트 메소드에서 매번 유저를 생성하는 대신 중앙화된 방식으로 관리하고 있습니다.
이러한 접근 방식은 특히 많은 테스트 케이스가 있는 클래스에서 유지보수성을 크게 향상시킵니다.
69-70: 테스트 내에서 일관된 유저 참조 방식을 사용했습니다.테스트 함수 내에서
테스트_유저변수를 일관되게 참조하여 코드의 가독성과 일관성을 높였습니다.Also applies to: 74-74
99-100: 복잡한 테스트 설정에서도 일관된 패턴을 유지했습니다.여러 객체를 생성하고 연관관계를 설정하는 복잡한 테스트에서도 fixture 패턴을 일관되게 적용했습니다. Repository 저장 작업을 유지하면서도 사용자 생성 로직은 fixture로 이동한 점이 좋습니다.
Also applies to: 102-102
120-120: 모든 테스트 케이스에서 일관된 방식으로 테스트 유저를 사용했습니다.여러 테스트 케이스에 걸쳐 동일한 방식으로 테스트 유저를 참조하여 일관성을 유지했습니다. 특히 여러 서비스 메소드 호출에서도 동일한 방식으로 사용자를 전달하는 패턴이 잘 적용되었습니다.
Also applies to: 135-135, 157-157
24-24: @beforeeach 사용을 위한 import 추가가 적절합니다.테스트 설정 방식 변경에 따른 import 추가가 잘 이루어졌습니다.
89-89: 모든 테스트에서 일관된 유저 참조 방식을 적용했습니다.다양한 테스트 메소드에서 동일한 방식으로
테스트_유저를 참조하여 코드의 일관성을 높였습니다.Also applies to: 105-105
src/test/java/com/example/solidconnection/concurrency/ThunderingHerdTest.java (4)
5-5: 픽스처 클래스 도입으로 테스트 코드 개선!SiteUserFixture 클래스를 도입하여 테스트 코드의 일관성과 재사용성을 높였습니다. 이는 PR 목표와 일치하는 변경사항입니다.
23-23: 가시성 및 의존성 개선변경 사항들:
- 클래스 가시성을 public에서 package-private으로 변경
- SiteUserRepository 대신 SiteUserFixture 사용
이런 변경은 테스트 코드의 캡슐화와 관리를 더 쉽게 만들어 줍니다.
Also applies to: 31-33
37-37: 한글 변수명 사용과 픽스처 활용
- siteUser 변수명을 한글인 '테스트_유저'로 변경
- setUp 메서드에서 SiteUserFixture를 활용하여 테스트 유저 생성
한글 변수명 사용은 도메인 언어의 일관성을 높여주며, 픽스처를 활용함으로써 테스트 설정 코드가 간결해졌습니다.
Also applies to: 41-42
57-59: 테스트 유저 활용 개선테스트 유저 객체를 일관되게 사용함으로써 테스트 코드의 가독성과 유지보수성이 향상되었습니다.
src/test/java/com/example/solidconnection/auth/service/EmailSignInServiceTest.java (3)
8-8: 픽스처 패턴 도입으로 의존성 개선
- SiteUserFixture 클래스를 가져오고 주입받도록 변경
- 기존 SiteUserRepository와 PasswordEncoder 의존성 제거
이 변경으로 테스트 코드의 유지보수성이 향상되었습니다.
Also applies to: 26-27
34-34: 테스트 유저 생성 방식 개선createSiteUser 헬퍼 메소드를 제거하고 SiteUserFixture를 통해 테스트 유저를 생성하도록 변경했습니다. 이로써 코드 중복이 제거되고 테스트 유저 생성 로직이 중앙화되었습니다.
65-65: 일관된 픽스처 사용 패턴실패 케이스에서도 동일하게 SiteUserFixture를 활용하여 테스트 유저를 생성함으로써 테스트 코드의 일관성을 유지했습니다.
src/test/java/com/example/solidconnection/custom/security/provider/SiteUserAuthenticationProviderTest.java (3)
8-8: 픽스처 패턴 적용 및 한글 변수명 사용
- SiteUserFixture 클래스 도입
- siteUser 변수명을 '테스트_유저'로 변경
- SiteUserRepository 의존성 제거
변경 사항이 PR의 일관성 개선 목표와 잘 일치합니다.
Also applies to: 39-41
45-46: 테스트 유저 생성 로직 간소화createSiteUser 메소드를 제거하고 SiteUserFixture를 통해 테스트 유저를 생성하도록 변경했습니다. 이로써 코드 중복이 제거되고 테스트 설정이 더 간결해졌습니다.
64-64: 토큰 생성 메소드 수정토큰 생성 메소드에서 사용하는 사용자 ID 참조를 '테스트_유저'를 사용하도록 일괄 수정하여 코드의 일관성을 유지했습니다.
Also applies to: 106-107, 128-128
src/test/java/com/example/solidconnection/concurrency/PostLikeCountConcurrencyTest.java (2)
9-9: 픽스처 패턴 도입SiteUserFixture 클래스를 추가하고 주입받아 테스트 사용자 생성에 활용함으로써 테스트 코드의 일관성을 높였습니다.
Also applies to: 43-44
55-55: 한글 변수명 사용 및 테스트 설정 개선
- siteUser 변수명을 '테스트_유저'로 변경
- setUp 메소드에서 SiteUserFixture를 활용하여 테스트 유저 생성
이러한 변경으로 테스트 코드의 일관성과 가독성이 향상되었습니다.
Also applies to: 61-62
src/test/java/com/example/solidconnection/siteuser/repository/SiteUserRepositoryTest.java (2)
20-21: Fixture 활용으로 코드가 단순해졌습니다.기존 SiteUserRepository 대신 SiteUserFixture를 주입받아 사용하도록 변경된 점이 좋습니다. 이를 통해:
- 테스트 데이터 생성 로직 중앙화
- 일관된 테스트 데이터 사용
- 코드 중복 제거
이런 방식은 테스트 코드의 가독성과 유지보수성을 크게 향상시킵니다.
29-29: 테스트 메서드에서 Fixture 활용이 잘 되었습니다.테스트 유저 생성을 위해
siteUserFixture.테스트_유저()메서드를 일관되게 사용한 점이 좋습니다. 이를 통해:
- 코드 중복이 줄어듦
- 테스트 데이터 생성 방식 통일
- 테스트 의도가 더 명확해짐
이전에는 아마도 직접 SiteUser 객체를 생성하고 저장하는 코드가 있었을 텐데, 이렇게 변경함으로써 코드가 더 간결하고 일관되게 되었습니다.
Also applies to: 32-32, 39-39, 42-42
src/test/java/com/example/solidconnection/university/service/UniversityLikeServiceTest.java (3)
38-39: 사용자 변수명 한글화로 일관성 향상SiteUserFixture 도입과 함께 변수명을
테스트_유저로 한글화한 것이 좋은 변경입니다. 이로 인해:
- 테스트 코드 전반에 걸친 명명 규칙의 일관성 증가
- 픽스처 메서드명(
테스트_유저())과의 일치로 가독성 향상- 도메인 용어를 한글로 통일하여 한국어 사용자에게 더 직관적인 코드
다른 테스트 클래스들과의 스타일 일관성을 유지하는 좋은 방향입니다.
Also applies to: 44-44
49-50: setUp에서 픽스처 활용이 잘 되었습니다.
@BeforeEach메서드에서 테스트 유저를 생성하는 방식이 깔끔하게 변경되었습니다:
siteUserFixture.테스트_유저()를 활용하여 일관된 방식으로 사용자 생성- 기존의 직접 사용자 생성 로직 제거로 코드 간소화
- 테스트 설정 단계에서의 명확성 증가
이 방식은 테스트 준비 단계를 더 읽기 쉽고 유지보수하기 쉽게 만듭니다.
59-66: 일관된 테스트 유저 참조 업데이트모든 테스트 메서드에서
테스트_유저변수 참조로 일관되게 변경된 점이 좋습니다. 이를 통해:
- 코드 전체적으로 일관된 스타일 유지
- 변수명이 기능을 더 명확하게 설명
- 한글 도메인 용어 사용으로 의도 전달력 향상
이런 일관성 있는 변경은 코드 가독성을 높이고 유지보수를 용이하게 합니다.
Also applies to: 73-73, 88-98, 105-117, 125-125, 137-137, 149-150
src/test/java/com/example/solidconnection/auth/service/AuthServiceTest.java (3)
34-37: 주입 순서 개선 및 Fixture 도입RedisTemplate과 SiteUserFixture의 주입 순서가 조정되고, SiteUserRepository 대신 SiteUserFixture를 사용하도록 변경한 점이 좋습니다:
- 의존성 주입 순서를 논리적으로 정리
- 테스트 데이터 생성 책임을 전문화된 클래스로 이동
- 중복 코드 제거 및 코드 재사용성 향상
이런 구조적 개선은 코드 가독성과 유지보수성을 높입니다.
59-64: 한글 변수명으로 테스트 의도 명확화
테스트_유저변수명 사용과 fixture를 통한 사용자 생성은 좋은 변경입니다:
- 테스트 의도를 더 명확하게 전달
- 다른 테스트 클래스와 일관된 스타일 유지
- 도메인 언어(한글)를 활용한 가독성 향상
이러한 일관성 있는 접근 방식은 전체 테스트 코드베이스의 품질을 향상시킵니다.
70-70: 일관된 변수명 변경탈퇴 테스트에서 검증 부분의 변수명도
테스트_유저로 일관되게 변경된 것이 좋습니다:
- 테스트 전체에서 일관된 명명 규칙 유지
- 한글 도메인 용어 사용으로 테스트 의도 명확화
- 코드 일관성 향상으로 가독성 증가
이런 세심한 변경은 테스트 코드의 전체적인 품질을 높이는 데 기여합니다.
src/test/java/com/example/solidconnection/admin/service/AdminLanguageTestScoreServiceTest.java (3)
42-43: SiteUserFixture 활용으로 코드 간소화SiteUserRepository 대신 SiteUserFixture를 주입받아 사용하도록 변경한 점이 좋습니다:
- 테스트 사용자 생성 로직 중앙화
- 테스트 설정 코드 간소화
- 다른 테스트 클래스와 일관된 접근 방식 유지
이러한 변경은 테스트 코드의 가독성과 유지보수성을 크게 향상시킵니다.
51-56: Fixture를 활용한 테스트 사용자 생성 개선테스트 사용자 생성 방식이 fixture를 활용하여 간결하게 변경되었습니다:
테스트_유저_1,테스트_유저_2,테스트_유저_3과 같은 한글 변수명 사용으로 의도 명확화siteUserFixture.테스트_유저()메서드로 일관된 사용자 생성- 인덱스와 닉네임을 파라미터로 전달하여 다양한 테스트 사용자 생성 가능
이런 방식은 테스트 데이터 준비 코드를 더 읽기 쉽고 유지보수하기 쉽게 만듭니다.
217-224: LanguageTestScore 생성 헬퍼 메서드 유지
createLanguageTestScore메서드를 유지한 것은 좋은 결정입니다:
- SiteUser 생성은 fixture로 위임하되, 특화된 LanguageTestScore 생성 로직은 유지
- 테스트 클래스 특화 로직과 공통 로직의 적절한 분리
- 메서드 이름이 목적을 명확히 나타내어 가독성 향상
이런 방식으로 공통 로직(사용자 생성)과 특화 로직(점수 생성)을 적절히 분리하는 것은 좋은 설계 결정입니다.
src/test/java/com/example/solidconnection/auth/service/SignInServiceTest.java (6)
7-7: SiteUserFixture 도입 - 테스트 코드 개선테스트 유저 생성을 중앙화하기 위해 SiteUserFixture를 도입한 변경이 훌륭합니다. 이 접근 방식은 다음과 같은 이점이 있습니다:
- 코드 중복 감소
- 테스트 데이터 생성 표준화
- 테스트 유지보수성 향상
31-36: 필드 주입 구조 개선필드 주입 구조를 개선하여 SiteUserRepository 대신 SiteUserFixture를 사용하는 방식으로 변경한 것이 적절합니다. 이렇게 하면:
- 테스트에서 직접적인 리포지토리 의존성을 제거
- 테스트 설정 간소화
- 관심사의 분리가 더 명확해짐
37-37: 변수명 한글화 - 가독성 개선
siteUser에서테스트_유저로 변수명을 한글화한 것은 코드의 가독성을 높이고 테스트 코드의 의도를 더 명확히 전달합니다. 국제화 프로젝트가 아니라면 테스트 코드에서 이런 방식의 네이밍은 매우 효과적입니다.
40-44: 테스트 설정 간소화setUp 메서드에서 테스트 유저 생성 방식을 개선했습니다:
- 기존의 복잡한 사용자 생성 코드 제거
- 픽스처를 통한 간결한 테스트 유저 생성
- 주제(subject) 설정 코드 유지하여 기능적 일관성 보장
테스트 설정이 훨씬 더 간결하고 이해하기 쉬워졌습니다.
49-49: 테스트 메서드 내 참조 변수명 통일테스트 메서드 내에서
siteUser대신테스트_유저를 일관되게 사용하여 코드의 일관성을 유지했습니다. 이는 테스트 코드 전체에 걸쳐 동일한 네이밍 컨벤션을 적용하는 좋은 예입니다.
64-67: 탈퇴 테스트 로직 간소화탈퇴 이력 초기화 테스트에서:
- 리포지토리 직접 접근을 제거하고 테스트 유저 객체에 직접 설정
- 테스트 로직을 더 명확하게 표현
- 픽스처 사용으로 불필요한 저장 단계 제거
이런 방식으로 테스트 의도가 더 명확해지고 코드가 간결해졌습니다.
src/test/java/com/example/solidconnection/siteuser/service/SiteUserServiceTest.java (5)
5-6: 필요한 임포트 추가 및 테스트 환경 설정 개선SiteUserFixture와 TestContainerSpringBootTest를 임포트하여 테스트 환경을 개선했습니다:
- 테스트 유저 생성을 위한 SiteUserFixture 임포트
- 테스트 컨테이너 사용을 위한 TestContainerSpringBootTest 임포트
이 변경을 통해 표준화된 테스트 환경 구성이 가능해졌습니다.
15-17: 테스트 클래스 구조 개선테스트 클래스의 구조를 개선했습니다:
- BaseIntegrationTest 상속 제거
- @TestContainerSpringBootTest 어노테이션 사용
- 표시 이름(DisplayName) 어노테이션 위치 조정
이러한 변경으로 테스트 구성이 더 명확하고 읽기 쉬워졌습니다.
22-25: 테스트 의존성 및 필드 변경테스트 클래스의 의존성 및 필드를 개선했습니다:
- SiteUserRepository 대신 SiteUserFixture 주입
- 테스트 유저를 위한 필드 추가 및 한글 네이밍 사용
이를 통해 테스트 코드의 가독성과 유지보수성이 향상되었습니다.
27-30: 테스트 설정 로직 간소화setUp 메서드의 로직을 간소화했습니다:
- 복잡한 사용자 생성 코드 제거
- 픽스처를 통한 간단한 테스트 유저 생성
- 리포지토리 직접 접근 대신 추상화된 인터페이스 사용
이 변경으로 테스트 설정 코드가 훨씬 간결해지고 이해하기 쉬워졌습니다.
38-38: 테스트 메서드 내 참조 변수 일관성 유지테스트 메서드 내에서
테스트_유저를 참조하도록 변경하여 일관성을 유지했습니다. 이는 리팩토링된 코드 전체에 걸쳐 동일한 네이밍 컨벤션을 적용한 좋은 예입니다.src/test/java/com/example/solidconnection/custom/resolver/AuthorizedUserResolverTest.java (4)
7-7: SiteUserFixture 도입으로 코드 표준화SiteUserFixture를 임포트하여 테스트 유저 생성 로직을 표준화했습니다. 이 방식은 모든 테스트 클래스에서 일관된 테스트 데이터 생성 패턴을 적용하는 데 도움이 됩니다.
31-33: 리포지토리 의존성을 픽스처로 대체SiteUserRepository 대신 SiteUserFixture를 주입받도록 변경했습니다:
- 테스트에서 직접적인 데이터베이스 접근 의존성 제거
- 테스트 유저 생성 로직 추상화
- 테스트 코드의 관심사 분리 개선
이런 변경은 테스트의 유지보수성과 가독성을 높입니다.
42-43: 테스트 유저 생성 방식 개선테스트 유저 생성 방식을 개선했습니다:
- 직접 생성 대신 SiteUserFixture 사용
- 한글 변수명(
테스트_유저) 적용으로 가독성 향상- 불필요한 헬퍼 메서드(createAndSaveSiteUser) 제거
이런 방식으로 테스트 코드가 더 간결하고 이해하기 쉬워졌습니다.
55-55: 테스트 검증 로직 일관성 유지검증 로직에서
테스트_유저변수를 사용하도록 변경하여 코드의 일관성을 유지했습니다. 이는 전체 리팩토링 과정에서 네이밍 컨벤션을 일관되게 적용한 좋은 예입니다.src/test/java/com/example/solidconnection/admin/service/AdminGpaScoreServiceTest.java (4)
12-12: SiteUserFixture 도입으로 표준화된 테스트 데이터 관리SiteUserFixture를 임포트하고 불필요한 임포트를 제거했습니다. 이 변경은 테스트 데이터 생성을 표준화하고 코드 가독성을 향상시킵니다.
38-43: 테스트 의존성 구조 개선테스트 의존성 구조를 개선했습니다:
- 필드 순서 재정렬로 관련 의존성 그룹화
- GpaScoreRepository 유지
- SiteUserRepository 제거 및 SiteUserFixture 추가
이러한 변경은 테스트 코드의 가독성과 유지보수성을 향상시킵니다.
49-56: 테스트 설정 로직 개선setUp 메서드의 로직을 개선했습니다:
- 직접 SiteUser 생성 대신 SiteUserFixture 사용
- 한글 변수명 적용 (
테스트_유저_1,테스트_유저_2,테스트_유저_3)- 여러 테스트 유저에 다른 식별자 부여 (id와 nickname)
- createGpaScore 메서드에 테스트 유저 전달 방식 유지
이런 방식으로 테스트 설정 코드가 더 일관되고 이해하기 쉬워졌습니다.
207-214: 헬퍼 메서드 유지 및 활용createGpaScore 헬퍼 메서드를 유지하면서 테스트 코드의 재사용성을 확보했습니다:
- SiteUser 파라미터를 받아 GpaScore를 생성하는 구조 유지
- 테스트 픽스처로 생성된 유저와 원활하게 통합
- 테스트에 필요한 다양한 상태(VerifyStatus)를 적용할 수 있는 유연성 유지
이 접근 방식은 코드 재사용성과 테스트 설정의 명확성을 균형있게 유지합니다.
src/test/java/com/example/solidconnection/siteuser/service/MyPageServiceTest.java (8)
8-15: 픽스처 임포트 추가 및 테스트 애노테이션 변경다음과 같은 변경사항이 적용되었습니다:
SiteUserFixture클래스 임포트 추가BaseIntegrationTest에서TestContainerSpringBootTest로 변경UniversityInfoForApplyFixture클래스 임포트 추가이러한 변경은 테스트 코드의 일관성과 재사용성을 높이는 좋은 방향입니다.
40-40: 테스트 애노테이션 변경
@BaseIntegrationTest에서@TestContainerSpringBootTest로 변경되었습니다. PR 설명에서 언급된 내용과 일치하며, 테스트 설정 간소화를 위한 적절한 변경입니다.
56-67: 테스트 픽스처 및 설정 메서드 추가다음과 같은 개선사항이 적용되었습니다:
SiteUserFixture와UniversityInfoForApplyFixture의존성 주입- 재사용 가능한
테스트_유저필드 추가@BeforeEach설정 메서드 구현이러한 변경은 테스트 코드의 중복을 줄이고 가독성을 높여줍니다. 각 테스트에서 개별적으로 사용자를 생성하는 대신 중앙 집중식 픽스처를 활용하는 방식은 매우 효과적입니다.
72-98: 테스트 메서드에서 픽스처 사용기존에 직접 생성하던 테스트 사용자 대신 픽스처에서 제공하는
테스트_유저를 사용하도록 변경되었습니다. 이는 테스트 코드의 일관성을 높이고 중복을 줄이는 좋은 접근 방식입니다.특히 line 97에서는 대학교 정보의 모든 필드 비교 대신 목록 크기만 확인하는 방식으로 단순화되어 테스트의 가독성이 향상되었습니다.
112-127: 이미지 업데이트 테스트에서 픽스처 사용테스트 유저를 직접 생성하지 않고 주입된 픽스처를 사용하도록 변경되었습니다. 이렇게 하면 테스트 코드의 일관성이 유지되고 중복 코드가 줄어듭니다.
132-145: 커스텀 프로필 테스트 사용자 픽스처 사용기존에 직접 생성하던 커스텀 프로필 테스트 사용자를 픽스처에서 제공하는 메서드를 통해 생성하도록 변경되었습니다. 이 변경은 코드 중복을 줄이고 테스트 설정의 일관성을 보장합니다.
175-180: 중복 닉네임 테스트에서 픽스처 사용중복 닉네임 테스트에서도 픽스처를 사용하여 테스트 사용자를 생성하도록 변경되었습니다. 이는 코드 중복을 줄이고 테스트 설정의 일관성을 높이는 좋은 방법입니다.
198-202: LikedUniversity 생성 시 픽스처 활용
createLikedUniversities메서드에서도 대학 정보를 픽스처에서 가져오도록 변경되었습니다. 이는 테스트 데이터 생성의 일관성을 높이고 코드 중복을 줄이는 긍정적인 변화입니다.src/test/java/com/example/solidconnection/concurrency/PostViewCountConcurrencyTest.java (7)
9-10: 임포트 변경 및 최적화다음과 같은 변경사항이 적용되었습니다:
SiteUserFixture클래스 임포트 추가- Redis 상수 임포트를 명확하게
VALIDATE_VIEW_COUNT_TTL만 사용하도록 최적화이러한 변경은 코드의 가독성과 유지보수성을 향상시킵니다.
Also applies to: 24-24
29-29: 클래스 접근 제한자 변경클래스 접근 제한자가
public에서 패키지 프라이빗으로 변경되었습니다. 이는 테스트 클래스의 가시성을 적절하게 제한하는 좋은 방법입니다.
43-56: SiteUserFixture 의존성 주입 및 필드 이름 변경다음과 같은 변경사항이 적용되었습니다:
SiteUserFixture의존성 추가- 테스트 사용자 필드명을 영문
testUser에서 한글테스트_유저로 변경이는 코드 스타일의 일관성을 유지하고 다른 테스트 클래스와의 통일성을 높이는 변경입니다.
58-64: 테스트 유저 생성 방식 개선
setUp메서드에서 직접 사용자를 생성하고 저장하는 대신SiteUserFixture를 사용하여 테스트 사용자를 생성하도록 변경되었습니다. 이는 코드 중복을 줄이고 테스트 설정의 일관성을 높이는 좋은 방법입니다.
86-89: 메서드 접근 제한자 변경 및 테스트 유저 참조 업데이트테스트 메서드의 접근 제한자가
public에서 패키지 프라이빗으로 변경되었으며, Redis 키 생성 시테스트_유저를 사용하도록 업데이트되었습니다. 이는 일관된 코드 스타일을 유지하는 적절한 변경입니다.
116-119: 조회수 조작 방지 테스트에서 테스트 유저 참조 업데이트테스트 메서드의 접근 제한자가 변경되었으며, Redis 키 생성 시
테스트_유저를 사용하도록 업데이트되었습니다. 이러한 변경은 코드의 일관성을 유지하는 데 도움이 됩니다.
126-140: Redis 키 생성 참조 업데이트Redis 조회 및 업데이트 로직에서
테스트_유저를 사용하도록 업데이트되었습니다. 이는 테스트 전체에서 일관된 사용자 참조를 유지하도록 하는 중요한 변경입니다.src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixtureBuilder.java (5)
1-13: 새로운 SiteUserFixtureBuilder 클래스 생성테스트용
SiteUser객체를 일관되게 생성할 수 있는 빌더 클래스가 추가되었습니다. 이 클래스는 다음과 같은 특징을 가집니다:
@TestComponent애노테이션을 통해 테스트 컨텍스트에서 빈으로 등록됨@RequiredArgsConstructor를 통한 생성자 주입- 빌더 패턴을 활용하여 유연한 객체 생성 지원
이는 테스트 코드의 가독성과 유지보수성을 크게 향상시키는 좋은 패턴입니다.
15-23: 필요한 필드 선언빌더에 필요한 모든 필드가 적절하게 선언되어 있습니다:
SiteUserRepository의존성SiteUser엔티티의 모든 필수 속성이러한 구조는
SiteUser엔티티의 변경에 따라 빌더도 쉽게 업데이트할 수 있게 해줍니다.
24-27: 새로운 빌더 인스턴스 생성 메서드
siteUser()메서드를 통해 새로운 빌더 인스턴스를 생성할 수 있도록 구현되었습니다. 이는 빌더 패턴의 일반적인 관행을 따르는 적절한 구현입니다.
28-56: 유연한 속성 설정을 위한 빌더 메서드각 속성을 설정할 수 있는, 메서드 체이닝을 지원하는 빌더 메서드들이 구현되었습니다:
email(String email)authType(AuthType authType)nickname(String nickname)profileImageUrl(String profileImageUrl)role(Role role)password(String password)각 메서드는
this를 반환하여 메서드 체이닝을 가능하게 합니다. 이는 빌더 패턴의 표준적인 구현으로 코드 가독성을 높여줍니다.
58-69: SiteUser 객체 생성 및 저장 메서드
create()메서드는 다음과 같은 기능을 제공합니다:
- 설정된 속성을 사용하여 새로운
SiteUser객체 생성- 기본
PreparationStatus.CONSIDERING상태 설정SiteUserRepository를 통한 객체 저장 및 반환이 접근 방식은 테스트에서 일관된 방식으로
SiteUser객체를 생성하고 저장할 수 있게 해주며, 테스트 코드의 중복을 줄입니다.src/test/java/com/example/solidconnection/university/service/UniversityRecommendServiceTest.java (7)
10-11: SiteUserFixture 의존성 추가다음과 같은 변경사항이 적용되었습니다:
SiteUserFixture클래스 임포트 추가SiteUserFixture의존성 주입이 변경을 통해 테스트 사용자 생성을 중앙화하고 표준화할 수 있습니다.
Also applies to: 42-44
54-55: 테스트 사용자 필드명 변경테스트 사용자 필드명이 영문
testUser에서 한글테스트_유저로 변경되었습니다. 이는 코드 스타일의 일관성을 유지하고 다른 테스트 클래스와의 통일성을 높이는 변경입니다.
64-75: setUp 메서드에서 테스트 유저 생성 방식 개선다음과 같은 변경사항이 적용되었습니다:
SiteUserFixture를 사용하여 테스트 사용자 생성- 몇몇 대학 정보 변수 초기화 제거 (메서드 호출만 유지)
이러한 변경은 테스트 설정을 간소화하고 코드 중복을 줄입니다.
81-82: 관심 지역 테스트에서 테스트 유저 참조 업데이트테스트 코드에서
테스트_유저를 사용하도록 업데이트되었습니다. 이는 일관된 사용자 참조를 유지하기 위한 중요한 변경입니다.
100-103: 관심 국가 테스트에서 테스트 유저 참조 업데이트관심 국가 설정 테스트에서도
테스트_유저를 사용하도록 업데이트되었습니다. 이는 전체 테스트에서 일관된 사용자 참조를 유지하기 위한 중요한 변경입니다.
117-121: 복합 테스트에서 테스트 유저 참조 업데이트관심 지역과 국가를 모두 설정하는 테스트에서도
테스트_유저를 사용하도록 업데이트되었습니다. 이는 테스트 코드의 일관성을 유지하는 데 중요한 변경입니다.
139-139: 미설정 사용자 테스트에서 테스트 유저 참조 업데이트관심사 미설정 사용자 테스트에서도
테스트_유저를 사용하도록 업데이트되었습니다. 모든 테스트에서 일관된 방식으로 테스트 사용자를 참조하도록 개선되었습니다.src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixture.java (6)
1-16: 클래스 구조와 의존성 주입이 잘 설계되었습니다.
TestComponent와 RequiredArgsConstructor 사용:
@TestComponent어노테이션으로 테스트 환경에서만 사용하도록 명확하게 지정했습니다.@RequiredArgsConstructor를 통한 의존성 주입이 깔끔합니다.의존성 관리:
- 필요한 의존성인
SiteUserFixtureBuilder와PasswordEncoder가 명확하게 정의되어 있습니다.- 빌더 패턴을 활용하여 테스트 데이터 생성 로직을 분리한 것이 좋습니다.
17-26: 기본 테스트 유저 생성 메서드가 잘 구현되었습니다.테스트 유저를 생성하는 기본 메서드가 명확하게 구현되어 있습니다. 빌더 패턴을 활용하여 가독성이 좋고, 필요한 모든 속성이 설정되어 있습니다.
39-48: 이메일과 인증 타입을 커스터마이징할 수 있는 메서드가 잘 구현되었습니다.테스트에서 다양한 인증 타입과 이메일 조합을 테스트할 수 있도록 잘 설계되었습니다.
61-70: 중복 닉네임 테스트 유저 메서드가 잘 구현되었습니다.닉네임 중복 테스트 시나리오에 대응할 수 있는 메서드가 잘 구현되어 있습니다.
72-81: 커스텀 프로필 테스트 유저 메서드가 잘 구현되었습니다.프로필 이미지 경로가 다른 메서드와 구분되어 있어 테스트 시나리오에 적합합니다.
83-92: 어드민 테스트 유저 메서드가 잘 구현되었습니다.어드민 권한이 필요한 테스트를 위한 메서드가 잘 구현되어 있습니다.
src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixture.java
Outdated
Show resolved
Hide resolved
src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixture.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixtureBuilder.java (3)
1-14: 클래스 문서화(Javadoc) 추가 권장테스트 코드의 가독성과 유지보수성을 높이기 위해 Javadoc을 추가하는 것이 좋습니다:
- 클래스 수준에서
SiteUserFixtureBuilder의 목적과 사용법을 설명하는 문서가 있으면 좋을 것 같습니다.- 이 빌더가 어떻게 사용되어야 하는지, 예시 코드도 포함하면 도움이 될 것입니다.
예시:
/** * 테스트용 SiteUser 엔티티를 생성하기 위한 빌더 클래스입니다. * 이 빌더는 테스트에서 일관된 방식으로 SiteUser 인스턴스를 생성하고 저장하는 데 사용됩니다. * * 사용 예시: * <pre> * SiteUser testUser = siteUserFixtureBuilder * .email("test@example.com") * .authType(AuthType.EMAIL) * .nickname("테스트유저") * .role(Role.USER) * .password("password123") * .create(); * </pre> */ @TestComponent @RequiredArgsConstructor public class SiteUserFixtureBuilder {
19-25: 기본값 설정 고려빌더 패턴에서는 일반적으로 모든 필드에 대해 합리적인 기본값을 제공하는 것이 좋습니다:
- 이렇게 하면 테스트 코드가 더 간결해지고 필요한 값만 변경할 수 있습니다.
- 현재는 기본값이 설정되어 있지 않아 모든 필드를 명시적으로 설정해야 합니다.
예시:
private final SiteUserRepository siteUserRepository; private final PasswordEncoder passwordEncoder; -private String email; -private AuthType authType; -private String nickname; -private String profileImageUrl; -private Role role; -private String password; +private String email = "default@example.com"; +private AuthType authType = AuthType.EMAIL; +private String nickname = "기본사용자"; +private String profileImageUrl = null; +private Role role = Role.USER; +private String password = "defaultPassword";
60-71: 테스트 유연성 향상을 위한 저장 로직 분리현재
create()메소드는 항상 엔티티를 저장합니다. 저장 없이 인스턴스만 생성하는 옵션을 추가하면 유연성이 높아집니다:
- 모든 테스트에서 DB 저장이 필요하지 않을 수 있습니다.
- 일부 단위 테스트는 실제 DB 연동 없이 SiteUser 객체만 필요할 수 있습니다.
제안 구현:
+/** + * SiteUser 인스턴스를 생성하지만 저장하지는 않습니다. + */ +public SiteUser build() { + if (email == null || authType == null || role == null) { + throw new IllegalStateException("필수 필드가 설정되지 않았습니다."); + } + + return new SiteUser( + email, + nickname, + profileImageUrl, + PreparationStatus.CONSIDERING, + role, + authType, + passwordEncoder.encode(password) + ); +} /** + * SiteUser 인스턴스를 생성하고 저장합니다. + */ public SiteUser create() { + SiteUser siteUser = build(); - SiteUser siteUser = new SiteUser( - email, - nickname, - profileImageUrl, - PreparationStatus.CONSIDERING, - role, - authType, - passwordEncoder.encode(password) - ); return siteUserRepository.save(siteUser); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixture.java(1 hunks)src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixtureBuilder.java(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixture.java
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: build
src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixtureBuilder.java
Show resolved
Hide resolved
src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixtureBuilder.java
Show resolved
Hide resolved
There was a problem hiding this comment.
전보다 가독성이 정말정말~~ 좋아졌습니다 🥹✨
하지만 저는 정말 만족을 모르는 것 같습니다🥲
몇가지 개선하면 좋겠다 싶은 부분을 기록용으로 남겨둡니다.
(지금 바꿀 필요성을 많이 느끼는 것도 아니고, 저도 대안이 있는 것은 아니니 반영은 하지 않으셔도 돼요!)
- 테스트유저(xx, xx)형식으로 되어있는 메서드 오버로딩이 많은데 이걸보고 각각의 인자가 뭔지 확인하려면 한번 들어가봐야햔다. 한번에 이해되는 것은 아님
siteUserFixture.테스트_유저()가 테스트 유저를 저장까지 한다는걸 코드를 보지 않고서는 모른다는게 아쉽다. 메서드 이름을테스트_유저_저장()같은걸로 바꾸면 되려나? 그런데 그러면 모든 fixture 함수 뒤에 xxx_저장()이 붙게되는건데 이게 맞나? 😵
제가 요즘 드는 생각은.. '결국에는 어디의 코드를 더럽힐 것인가의 문제'라는 것입니다.
결국 약간의 더러운 코드는 더 중요한 코드를 우아하게 만들기 위해 필연적인걸수도 있겠다는 생각을 합니다.
더러움 보존의 법칙이랄까요^^
지금도 테스트 코드의 가독성을 위해서,
그리고 연관된 도메인을 어떤 순서로 저장해야하는지를 몰라되 된다는 간편함과,
그 데이터 세팅을 위한 given 절을 줄이기 위해서
픽스쳐를 만들고 있습니다.
그런데 여기에서도 조금 더 나은 방법을 고민하는 제가
"없어지지 않는 더러움을 끝끝내 없애려는" 어리석은 짓을 하고 있는건 아닌가~ 라는 생각이 들기도 하고요😅
한편으로는 불가능한 것을 규혁님께 말씀드려 괜히 마음을 어렵게 만드는건가 싶어 뜨끔하는 마음이 들기도 했습니다.
그래도 더러운 코드는 최소화하는게 좋으니깐요..
이게 해소될 순 없더라도 불편함을 부분을 공유하는건 의미있는 일이라 생각해서 말씀드려봐요!!
새벽이라 이런저런 넉두리를 적어봤습니다 🌛
| public SiteUser 테스트_유저() { | ||
| return siteUserFixtureBuilder.siteUser() | ||
| .email("test@example.com") | ||
| .authType(AuthType.EMAIL) | ||
| .nickname("테스트유저") | ||
| .profileImageUrl("profileImageUrl") | ||
| .role(Role.MENTEE) | ||
| .password("password123") | ||
| .create(); | ||
| } |
There was a problem hiding this comment.
이 함수의 이름을 테스트_유저()로 하신 이유가 있나요?
제 생각에는 대학이나 지원 정보도 앞에 "테스트"를 명시하지 않았던 것처럼,
SiteUser를 만드는 메서드도 "테스트"가 없도록 통일하면 좋을 것 같아요!
사용자(), 혹은 회원() 같은 이름은 어떤가요?
그리고 siteUserFixture로부터 호출하고 있기에, 이미 테스트를 위한 함수라는 것도 드러내고 있어서 동어 반복처럼 느껴지기도 하네요.
There was a problem hiding this comment.
그러네요 대학쪽이랑 일관성이 없게 제가 만들어버렸네요 😅 반영하겠습니다!
| SiteUser 테스트_유저_1 = siteUserFixture.테스트_유저(1, "test1"); | ||
| SiteUser 테스트_유저_2 = siteUserFixture.테스트_유저(2, "test2"); | ||
| SiteUser 테스트_유저_3 = siteUserFixture.테스트_유저(3, "test3"); |
There was a problem hiding this comment.
여기에도 "테스트_" 를 붙이신 이유가 있으신가요?
fixture 생성 함수에서도 그렇고, 변수명에서도 사용되니 규혁님이 이렇게 하신게 의도적일거라는 생각이 드네요~ 왜 이렇게 하셨는지 궁금합니다!
There was a problem hiding this comment.
위에 이야기를 듣고 나니 안붙이는 게 더 좋을 거 같다는 생각이 드네요! 새벽에 작업했었는데 깊게 생각하지 않고 작성했던 거 같아요 😅
| @Autowired | ||
| private SiteUserRepository siteUserRepository; | ||
| private LanguageTestScoreRepository languageTestScoreRepository; | ||
|
|
||
| @Autowired | ||
| private LanguageTestScoreRepository languageTestScoreRepository; | ||
| private SiteUserFixture siteUserFixture; |
There was a problem hiding this comment.
Fixture 를 맨 아래로 두신건 이게 덜중요하다는 생각 때문인가요?!
There was a problem hiding this comment.
앗 주로 테스트를 하는 AdminLanguageTestScoreService를 제일 위에서 주입받는 게 일단 맞다고 생각했습니다!
LanguageTestScoreRepository는 어차피 Fixture가 생기면 없어질 의존성이니 크게 신경을 안썼는데 주석으로 표시하면 좋았겠네요
There was a problem hiding this comment.
의도가 궁금해서 질문드렸던거였어요 ㅎㅎ
답변 감사합니다!
| @Autowired | ||
| private PostLikeService postLikeService; | ||
|
|
||
| @Autowired | ||
| private PostRepository postRepository; | ||
|
|
There was a problem hiding this comment.
PR 범위에서 조금 벗어나더라도 이정도 사소한 리팩터링은 포함되는게 좋다 생각합니다 ㅎㅎ
개행 잘 추가하셨어요~~
| public SiteUser 중복_닉네임_테스트_유저() { | ||
| return siteUserFixtureBuilder.siteUser() | ||
| .email("duplicated@example.com") | ||
| .authType(AuthType.EMAIL) | ||
| .nickname("중복닉네임") | ||
| .profileImageUrl("profileImageUrl") | ||
| .role(Role.MENTEE) | ||
| .password("password123") | ||
| .create(); | ||
| } | ||
|
|
||
| public SiteUser 커스텀_프로필_테스트_유저() { | ||
| return siteUserFixtureBuilder.siteUser() | ||
| .email("customProfile@example.com") | ||
| .authType(AuthType.EMAIL) | ||
| .nickname("커스텀프로필") | ||
| .profileImageUrl("profile/profileImageUrl") | ||
| .role(Role.MENTEE) | ||
| .password("customPassword123") | ||
| .create(); | ||
| } | ||
|
|
There was a problem hiding this comment.
이 두 fixture는 호출하는 곳이 한곳밖에 없고, 앞으로의 재사용성도 떨어진다 생각하는데 private 함수로 만드는건 어떤가요?
There was a problem hiding this comment.
그게 좋겠네요! 더 사용될 일도 없을 것 같은 코드네요
| @Test | ||
| void 중복된_닉네임으로_변경하면_예외_응답을_반환한다() { | ||
| // given | ||
| createDuplicatedSiteUser(); | ||
| SiteUser testUser = createSiteUser(); | ||
| SiteUser 중복_닉네임_테스트_유저 = siteUserFixture.중복_닉네임_테스트_유저(); | ||
| MockMultipartFile imageFile = createValidImageFile(); | ||
|
|
||
| // when & then | ||
| assertThatCode(() -> myPageService.updateMyPageInfo(testUser, imageFile, "duplicatedNickname")) | ||
| assertThatCode(() -> myPageService.updateMyPageInfo(테스트_유저, imageFile, 중복_닉네임_테스트_유저.getNickname())) | ||
| .isInstanceOf(CustomException.class) | ||
| .hasMessage(NICKNAME_ALREADY_EXISTED.getMessage()); | ||
| } |
There was a problem hiding this comment.
이 함수 전체가 이렇게 바뀐다면
SiteUser existingUser = siteUserFixture.테스트_유저(1, "existing nickname");
// when & then
assertThatCode(() -> myPageService.updateMyPageInfo(테스트_유저, null, existingUser.getNickname()))
.isInstanceOf(CustomException.class)
.hasMessage(NICKNAME_ALREADY_EXISTED.getMessage());중복_닉네임_테스트_유저()가 필요하지 않게되는데 이건 어떤가요?
There was a problem hiding this comment.
음.. 전 A유저가 기존 A유저의 닉네임으로 바꾸는 걸 테스트하는 게 아니라 A유저가 기존 B유저의 닉네임으로 바꾸는 걸 테스트 해야 유의미한 테스트라고 생각하긴 했는데 상관 없다고 생각하시는건가요??
There was a problem hiding this comment.
A유저가 기존 B유저의 닉네임으로 바꾸는 걸 테스트 해야 유의미한 테스트라고 생각하긴 했는데
위에 제가 적은 코드에서,
- beforeEach에서 생성한 "테스트_유저" : A 유저
- 제가 테스트코드 내부에서 생성한 "existingUser" : 기존 B 유저
라고 본다면 규혁님이 생각하신것과 동일한걸 테스트하고 있어요!
혹시 제가 다르게 이해하고 있는게 있다면 말씀해주세요~
There was a problem hiding this comment.
아 그러네요!😅
myPageService.updateMyPageInfo(테스트_유저, null, existingUser.getNickname())
여기에 들어간 유저를 existingUser로 착각했네요.. 좋습니다!!
| // @TestContainerDataJpaTest + @Import 쓰기 vs @TestContainerSpringBootTest 검토 필요 | ||
| @TestContainerSpringBootTest | ||
| //@Import({SiteUserFixture.class, SiteUserFixtureBuilder.class, PasswordEncoder.class}) | ||
| @DisplayName("유저 레포지토리 테스트") |
There was a problem hiding this comment.
@TestContainerDataJpaTest + import 쓰기 vs @TestContainerSpringBootTest 중 어떤 걸로 해야할지 고민이 되었습니다!
- 저는 레포지토리를 테스트하는 이 테스트 코드에서는 레포지토리 자체에 대해 테스트를 하는게 맞다 생각해서, when절에서 siteUserFixture.테스트_유저()가 아니라 siteUserRepository.save()를 직접 호출하는게 좋다 생각해요.
- 비슷한 의미에서, 우리가 테스트하려는것이 엔티티의 값에 따라서 어떻게 저장되는지에 대한 것이니, 엔티티 자체를 쓰는게 좋을 것 같아요.
결론 :: 규혁님의 질문에 대한 답변은 '이 테스트코드에서는 fixture를 쓰기보다 엔티티와 레포지토리를 그대로 사용하는게 좋아보인다'입니다!
There was a problem hiding this comment.
아하 그게 좋겠네요 좋습니다!!
저도 작성하면서 들었던 생각인데 오버로딩의 단점을 해결하고자 저희는 메서드 체이닝 방식을 사용했습니다. 그렇다면 테스트 할 때마다 거기서 메서드체이닝으로 생성을 해야할까?라는 생각이 들었지만 given()절이 결국 또 더러워지고 이전에 컬럼 두 개 수정했다가 모든 테스트 코드들을 수정하는 문제가 또 발생할 거 같습니다 🥲 정말 쉽지않네요 ㅠㅠ |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixture.java (1)
1-68: 전체적인 Fixture 설계에 대한 제안 사항이 있습니다.전체적으로 잘 설계된 Fixture 클래스입니다만, 다음과 같은 개선 사항을 고려해보세요:
메서드 오버로딩의 명확성 향상:
- 현재 여러 오버로딩된
사용자()메서드가 있어 메서드 시그니처만으로는 각 매개변수의 의미를 파악하기 어렵습니다.- 메서드 이름을 더 명확하게 만들어 보세요. 예:
사용자_이메일_비밀번호지정(email, password),사용자_인덱스_닉네임지정(index, nickname)저장 동작의 명시성:
- 현재 모든 메서드가 사용자를 생성하고 저장합니다. 이 동작이 메서드 이름에서 명확하지 않습니다.
- PR 코멘트에서 언급한 것처럼
사용자_저장()형태로 이름을 변경하거나, 저장하지 않는 별도 메서드도 제공하는 것을 고려해보세요.일부 메서드의 가시성:
- 사용 빈도가 낮은 메서드는 private으로 설정하는 것을 고려해보세요.
- PR 코멘트에서 언급된 것처럼 재사용성이 낮은 메서드는 숨기는 것이 API를 더 깔끔하게 만들 수 있습니다.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge Base: Disabled due to data retention organization setting
📒 Files selected for processing (22)
src/test/java/com/example/solidconnection/admin/service/AdminGpaScoreServiceTest.java(2 hunks)src/test/java/com/example/solidconnection/admin/service/AdminLanguageTestScoreServiceTest.java(2 hunks)src/test/java/com/example/solidconnection/auth/service/AuthServiceTest.java(3 hunks)src/test/java/com/example/solidconnection/auth/service/EmailSignInServiceTest.java(3 hunks)src/test/java/com/example/solidconnection/auth/service/SignInServiceTest.java(3 hunks)src/test/java/com/example/solidconnection/community/post/service/PostCommandServiceTest.java(14 hunks)src/test/java/com/example/solidconnection/community/post/service/PostLikeServiceTest.java(5 hunks)src/test/java/com/example/solidconnection/community/post/service/PostQueryServiceTest.java(4 hunks)src/test/java/com/example/solidconnection/concurrency/PostLikeCountConcurrencyTest.java(2 hunks)src/test/java/com/example/solidconnection/concurrency/PostViewCountConcurrencyTest.java(5 hunks)src/test/java/com/example/solidconnection/concurrency/ThunderingHerdTest.java(3 hunks)src/test/java/com/example/solidconnection/custom/resolver/AuthorizedUserResolverTest.java(4 hunks)src/test/java/com/example/solidconnection/custom/security/aspect/AdminAuthorizationAspectTest.java(3 hunks)src/test/java/com/example/solidconnection/custom/security/provider/SiteUserAuthenticationProviderTest.java(5 hunks)src/test/java/com/example/solidconnection/custom/security/userdetails/SiteUserDetailsServiceTest.java(3 hunks)src/test/java/com/example/solidconnection/custom/security/userdetails/SiteUserDetailsTest.java(2 hunks)src/test/java/com/example/solidconnection/score/service/ScoreServiceTest.java(7 hunks)src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixture.java(1 hunks)src/test/java/com/example/solidconnection/siteuser/service/MyPageServiceTest.java(7 hunks)src/test/java/com/example/solidconnection/siteuser/service/SiteUserServiceTest.java(3 hunks)src/test/java/com/example/solidconnection/university/service/UniversityLikeServiceTest.java(7 hunks)src/test/java/com/example/solidconnection/university/service/UniversityRecommendServiceTest.java(6 hunks)
🚧 Files skipped from review as they are similar to previous changes (18)
- src/test/java/com/example/solidconnection/custom/security/userdetails/SiteUserDetailsTest.java
- src/test/java/com/example/solidconnection/concurrency/PostLikeCountConcurrencyTest.java
- src/test/java/com/example/solidconnection/custom/security/aspect/AdminAuthorizationAspectTest.java
- src/test/java/com/example/solidconnection/score/service/ScoreServiceTest.java
- src/test/java/com/example/solidconnection/concurrency/ThunderingHerdTest.java
- src/test/java/com/example/solidconnection/auth/service/EmailSignInServiceTest.java
- src/test/java/com/example/solidconnection/custom/security/userdetails/SiteUserDetailsServiceTest.java
- src/test/java/com/example/solidconnection/custom/security/provider/SiteUserAuthenticationProviderTest.java
- src/test/java/com/example/solidconnection/university/service/UniversityLikeServiceTest.java
- src/test/java/com/example/solidconnection/auth/service/SignInServiceTest.java
- src/test/java/com/example/solidconnection/admin/service/AdminLanguageTestScoreServiceTest.java
- src/test/java/com/example/solidconnection/custom/resolver/AuthorizedUserResolverTest.java
- src/test/java/com/example/solidconnection/siteuser/service/MyPageServiceTest.java
- src/test/java/com/example/solidconnection/admin/service/AdminGpaScoreServiceTest.java
- src/test/java/com/example/solidconnection/university/service/UniversityRecommendServiceTest.java
- src/test/java/com/example/solidconnection/auth/service/AuthServiceTest.java
- src/test/java/com/example/solidconnection/siteuser/service/SiteUserServiceTest.java
- src/test/java/com/example/solidconnection/concurrency/PostViewCountConcurrencyTest.java
🧰 Additional context used
🧬 Code Graph Analysis (1)
src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixture.java (1)
src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixtureBuilder.java (1)
TestComponent(12-72)
🔇 Additional comments (50)
src/test/java/com/example/solidconnection/community/post/service/PostQueryServiceTest.java (8)
16-16: 필요한 import가 적절하게 추가되었습니다.SiteUserFixture를 사용하기 위한 import 문이 깔끔하게 추가되었네요.
53-54: SiteUserFixture 의존성 주입이 잘 구현되었습니다.SiteUserFixture를 @Autowired로 주입받아 테스트에서 사용할 수 있도록 잘 설정되었습니다.
56-56: 테스트 사용자 필드 선언이 명확합니다.여러 테스트 메서드에서 재사용할 SiteUser 필드가 간결하게 선언되었습니다.
58-61: @beforeeach 메서드에서 테스트 사용자 초기화가 잘 구현되었습니다.각 테스트 실행 전에 사용자 객체를 일관되게 초기화하는 방식이 좋습니다. 재사용성과 가독성이 높아졌습니다.
118-119: 테스트 데이터 생성 방식이 개선되었습니다.기존의 하드코딩된 사용자 참조 대신 fixture를 통해 생성된 user 객체를 사용함으로써 일관성과 유지보수성이 향상되었습니다.
121-121: Redis 키 생성 코드가 일관되게 수정되었습니다.Fixture로 생성된 user 객체의 ID를 사용하여 Redis 키를 생성하도록 변경되었습니다.
126-126: 서비스 메서드 호출 시 사용자 객체 전달이 적절합니다.Fixture로 생성된 user 객체를 서비스 메서드 파라미터로 전달하는 방식이 일관성 있게 적용되었습니다.
143-145: 응답 검증 로직이 깔끔하게 수정되었습니다.응답의 사용자 관련 필드를 검증하는 부분이 fixture로 생성된 user 객체의 속성과 비교하도록 일관되게 수정되었습니다.
src/test/java/com/example/solidconnection/community/post/service/PostLikeServiceTest.java (14)
11-11: 필요한 import가 적절하게 추가되었습니다.SiteUserFixture를 사용하기 위한 import 문이 깔끔하게 추가되었네요.
38-40: SiteUserFixture 의존성 주입이 잘 구현되었습니다.SiteUserFixture를 @Autowired로 주입받아 테스트에서 사용할 수 있도록 잘 설정되었습니다.
41-41: 테스트 사용자 필드 선언이 명확합니다.여러 테스트 메서드에서 재사용할 SiteUser 필드가 간결하게 선언되었습니다.
43-46: @beforeeach 메서드에서 테스트 사용자 초기화가 잘 구현되었습니다.각 테스트 실행 전에 사용자 객체를 일관되게 초기화하는 방식이 좋습니다. 재사용성과 가독성이 높아졌습니다.
54-54: 테스트 데이터 생성 방식이 개선되었습니다.fixture를 통해 생성된 user 객체를 사용하여 Post를 생성함으로써 테스트 데이터 생성의 일관성이 향상되었습니다.
59-60: 서비스 메서드 호출 시 사용자 객체 전달이 적절합니다.Fixture로 생성된 user 객체를 서비스 메서드 파라미터로 전달하는 방식이 일관성 있게 적용되었습니다.
69-69: 검증 로직이 일관되게 수정되었습니다.좋아요 저장소에서 조회 시 fixture로 생성된 user 객체를 사용하도록 변경되었습니다.
76-77: 테스트 데이터 및 서비스 호출이 일관되게 수정되었습니다.fixture를 통해 생성된 user 객체를 사용하여 Post 생성 및 좋아요 서비스를 호출하도록 변경되었습니다.
82-83: 예외 상황 테스트에서 사용자 객체 전달이 적절합니다.예외 테스트에서도 fixture로 생성된 user 객체를 사용하여 일관성을 유지하고 있습니다.
96-98: 게시글 좋아요 취소 테스트에서 사용자 객체 사용이 일관적입니다.게시글 생성 및 좋아요 서비스 호출 시 fixture로 생성된 user 객체를 일관되게 사용하고 있습니다.
102-103: 좋아요 취소 서비스 호출 시 사용자 객체 전달이 적절합니다.좋아요 취소 메서드 호출 시에도 fixture로 생성된 user 객체를 일관되게 사용하고 있습니다.
112-112: 검증 로직이 일관되게 수정되었습니다.좋아요 취소 후 저장소 조회 시 fixture로 생성된 user 객체를 사용하도록 변경되었습니다.
119-119: 예외 테스트 데이터 생성이 일관되게 수정되었습니다.좋아요하지 않은 게시글 테스트에서도 fixture로 생성된 user 객체를 사용하여 일관성을 유지하고 있습니다.
124-125: 예외 상황 테스트에서의 서비스 호출이 일관됩니다.좋아요 취소 예외 테스트에서도 fixture로 생성된 user 객체를 사용하여 일관성을 유지하고 있습니다.
src/test/java/com/example/solidconnection/community/post/service/PostCommandServiceTest.java (22)
18-18: 필요한 import가 적절하게 추가되었습니다.SiteUserFixture를 사용하기 위한 import 문이 깔끔하게 추가되었네요.
68-70: SiteUserFixture 의존성 주입이 잘 구현되었습니다.SiteUserFixture를 @Autowired로 주입받아 테스트에서 사용할 수 있도록 잘 설정되었습니다.
71-71: 테스트 사용자 필드 선언이 명확합니다.여러 테스트 메서드에서 재사용할 SiteUser 필드가 간결하게 선언되었습니다.
73-76: @beforeeach 메서드에서 테스트 사용자 초기화가 잘 구현되었습니다.각 테스트 실행 전에 사용자 객체를 일관되게 초기화하는 방식이 좋습니다. 재사용성과 가독성이 높아졌습니다.
93-94: 게시글 생성 서비스 호출 시 사용자 객체 전달이 적절합니다.fixture로 생성된 user1 객체를 서비스 메서드 파라미터로 전달하는 방식이 깔끔합니다.
122-122: 예외 테스트에서의 서비스 호출이 일관됩니다.예외 테스트에서도 fixture로 생성된 user1 객체를 사용하여 일관성을 유지하고 있습니다.
135-135: 존재하지 않는 카테고리 테스트에서도 일관성이 유지됩니다.예외 테스트에서도 fixture로 생성된 user1 객체를 사용하여 일관성을 유지하고 있습니다.
148-148: 이미지 제한 초과 테스트에서의 서비스 호출이 일관됩니다.예외 테스트에서도 fixture로 생성된 user1 객체를 사용하여 일관성을 유지하고 있습니다.
163-163: 테스트 게시글 생성 시 사용자 객체 사용이 개선되었습니다.fixture로 생성된 user1 객체를 사용하여 테스트 게시글을 생성함으로써 일관성이 향상되었습니다.
172-173: 게시글 수정 서비스 호출 시 사용자 객체 전달이 적절합니다.fixture로 생성된 user1 객체를 서비스 메서드 파라미터로 전달하는 방식이 일관됩니다.
195-196: 다른 사용자 테스트에서의 사용자 생성 방식이 개선되었습니다.다른 사용자 테스트에서도 SiteUserFixture를 사용하여 일관되게 사용자 객체를 생성하고 있습니다.
203-204: 다른 사용자 예외 테스트에서의 서비스 호출이 일관됩니다.다른 사용자 예외 테스트에서도 fixture로 생성된 user2 객체를 사용하여 일관성을 유지하고 있습니다.
215-215: 테스트 질문 게시글 생성 시 사용자 객체 사용이 개선되었습니다.fixture로 생성된 user1 객체를 사용하여 테스트 질문 게시글을 생성함으로써 일관성이 향상되었습니다.
222-223: 질문 게시글 수정 예외 테스트에서의 서비스 호출이 일관됩니다.질문 게시글 수정 예외 테스트에서도 fixture로 생성된 user1 객체를 사용하여 일관성을 유지하고 있습니다.
234-234: 이미지 제한 초과 테스트에서의 게시글 생성이 일관됩니다.이미지 제한 초과 테스트에서도 fixture로 생성된 user1 객체를 사용하여 테스트 게시글을 생성하고 있습니다.
241-242: 이미지 제한 초과 테스트에서의 서비스 호출이 일관됩니다.이미지 제한 초과 테스트에서도 fixture로 생성된 user1 객체를 사용하여 일관성을 유지하고 있습니다.
258-258: 게시글 삭제 테스트에서의 게시글 생성이 일관됩니다.게시글 삭제 테스트에서도 fixture로 생성된 user1 객체를 사용하여 테스트 게시글을 생성하고 있습니다.
264-265: 게시글 삭제 서비스 호출 시 사용자 객체 전달이 적절합니다.fixture로 생성된 user1 객체를 서비스 메서드 파라미터로 전달하는 방식이 일관됩니다.
280-281: 다른 사용자 삭제 테스트에서의 사용자 생성 방식이 개선되었습니다.다른 사용자 삭제 테스트에서도 SiteUserFixture를 사용하여 일관되게 사용자 객체를 생성하고 있습니다.
286-287: 다른 사용자 삭제 예외 테스트에서의 서비스 호출이 일관됩니다.다른 사용자 삭제 예외 테스트에서도 fixture로 생성된 user2 객체를 사용하여 일관성을 유지하고 있습니다.
296-296: 질문 게시글 삭제 테스트에서의 게시글 생성이 일관됩니다.질문 게시글 삭제 테스트에서도 fixture로 생성된 user1 객체를 사용하여 테스트 게시글을 생성하고 있습니다.
301-302: 질문 게시글 삭제 예외 테스트에서의 서비스 호출이 일관됩니다.질문 게시글 삭제 예외 테스트에서도 fixture로 생성된 user1 객체를 사용하여 일관성을 유지하고 있습니다.
src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixture.java (6)
9-14: Fixture 클래스 구조가 잘 설계되었습니다.
@TestComponent어노테이션을 사용하여 테스트 환경에서만 사용되는 컴포넌트임을 명확히 표시했습니다.@RequiredArgsConstructor를 통해 생성자 주입을 간결하게 구현했습니다.SiteUserFixtureBuilder의존성을 주입받아 사용자 생성을 위임하는 구조가 잘 설계되었습니다.이런 구조는 테스트 코드의 재사용성과 유지보수성을 크게 향상시킵니다.
15-24: 기본 사용자 생성 메서드가 잘 구현되었습니다.메서드
사용자()는 기본 값으로 사용자 객체를 생성하며, 빌더 패턴을 사용하여 읽기 쉽고 명확한 구조를 가지고 있습니다. 이 메서드는 특별한 요구사항 없이 기본 테스트 사용자가 필요한 경우에 유용합니다.
26-35: 인덱스와 닉네임을 사용한 사용자 생성 메서드가 유용합니다.
사용자(int index, String nickname)메서드는 여러 테스트 사용자를 생성할 때 매우 유용합니다. 인덱스를 통해 이메일을 구분하고, 닉네임을 직접 지정할 수 있어 테스트 시나리오별 사용자를 쉽게 식별할 수 있습니다.
37-46: 이메일과 인증 타입을 지정하는 사용자 생성 메서드가 잘 구현되었습니다.
사용자(String email, AuthType authType)메서드는 다양한 인증 방식(이메일, 소셜 로그인 등)을 테스트할 때 유용합니다. 이메일과 인증 타입을 명시적으로 지정할 수 있어 특정 인증 시나리오를 테스트하기에 적합합니다.
48-57: 이메일과 비밀번호를 지정하는 사용자 생성 메서드가 유용합니다.
사용자(String email, String password)메서드는 로그인 테스트와 같이 특정 비밀번호를 가진 사용자가 필요한 경우에 유용합니다. 이메일과 비밀번호를 명시적으로 지정할 수 있어 인증 관련 테스트에 적합합니다.
59-68: 관리자 사용자 생성 메서드가 잘 구현되었습니다.
관리자()메서드는 관리자 권한이 필요한 테스트 시나리오에 적합합니다. Role.ADMIN 역할을 가진 사용자를 생성하며, 기본값으로 관리자 이메일과 비밀번호를 설정하여 관리자 테스트를 간편하게 수행할 수 있습니다.
src/test/java/com/example/solidconnection/siteuser/service/MyPageServiceTest.java
Outdated
Show resolved
Hide resolved
src/test/java/com/example/solidconnection/siteuser/service/MyPageServiceTest.java
Outdated
Show resolved
Hide resolved
src/test/java/com/example/solidconnection/siteuser/fixture/SiteUserFixture.java
Show resolved
Hide resolved
3 participants
관련 이슈
작업 내용
유저 관련 통합 테스트 데이터 fixture 메서드로 변경했습니다
쪼개기가 애매한 거 같아서 어쩌다보니 pr이 조금 커졌네요...
#275 때같은 문제가 이제 발생하지 않겠네요
특이 사항
리뷰 요구사항 (선택)
뒷 부분은 그냥 단순 노동이었습니다. 😅
@TestContainerDataJpaTest + @import 쓰기 vs @TestContainerSpringBootTest 중 어떤 걸로 해야할지 고민이 되었습니다!