chore: 테스트용 Base 클래스 및 워크플로우 .env 구성(#17)

[hisonghy]

📌 작업 내용 및 특이사항

✅ 테스트용 Base 클래스 추가

• 통합 테스트 코드에서 공통 설정을 재사용할 수 있도록 BaseIntegrationTest 클래스를 추가했습니다.
  : 통합 테스트 작성 시에, extends BaseIntegrationTest로 상속해서 사용하면 될 것 같습니다.
  : 추후 멤버 생성 로직과 로그인 로직과 같이 공통으로 자주 사용되는 로직을, BaseIntegrationTest에 공통 엔티티 생성 메서드나 유틸 메서드를 추가해 테스트 코드 중복을 줄이면 좋을 것 같습니다. (주석 TODO로 적어두었습니다.)

• 단위 테스트 코드에서 공통 설정을 재사용할 수 있도록 BaseUnitTest 클래스를 추가했습니다.
  : 통합 Base 클래스와 동일하게 추후 공통으로 자주 사용되는 로직을 추가하면 좋을 것 같습니다.

✅ develop PR 워크플로우 .env 파일 생성 스텝 추가

• develop_pull_request 워크플로우에서 테스트를 실행하기 전에 .env 파일을 생성하는 스텝을 추가했습니다.
  : 통합 테스트에서 .env 파일을 읽도록 설정했기 때문에, .env 파일을 추가하도록 구성했습니다.
  : 테스트에 필요한 환경변수들은 GitHub Secrets에 TEST_ENV로 등록해두었습니다.

🌱 관련 이슈

• close ⚙️[CHORE]: 테스트용 Base 클래스 구성 #17

🔍 참고사항(선택)

📚 기타(선택)

[chaiminwoo0223]

Base 클래스 설계가 깔끔하고 공통 설정이 잘 분리되어 있어서 테스트 환경 구성이 편리할 것 같습니다!
다만, 도메인 객체 생성 및 인증 관련 로직까지 Base에서 관리하게 되면 관심사 분리 원칙이 흐려질 수 있어서, 해당 로직은 별도 Fixture 또는 Helper 클래스로 분리하는게 좋을 것 같아요~^^

[hisonghy]

Base 클래스 설계가 깔끔하고 공통 설정이 잘 분리되어 있어서 테스트 환경 구성이 편리할 것 같습니다!

다만, 도메인 객체 생성 및 인증 관련 로직까지 Base에서 관리하게 되면 관심사 분리 원칙이 흐려질 수 있어서, 해당 로직은 별도 Fixture 또는 Helper 클래스로 분리하는게 좋을 것 같아요~^^

그럼 도메인 객체 생성 등 로직은 각자 도매인별 테스트 코드를 작성하면서 함께 따로 구현하는게 좋을것같다는 말씀이신거죠?

[chaiminwoo0223]

Base 클래스 설계가 깔끔하고 공통 설정이 잘 분리되어 있어서 테스트 환경 구성이 편리할 것 같습니다!
다만, 도메인 객체 생성 및 인증 관련 로직까지 Base에서 관리하게 되면 관심사 분리 원칙이 흐려질 수 있어서, 해당 로직은 별도 Fixture 또는 Helper 클래스로 분리하는게 좋을 것 같아요~^^

그럼 도메인 객체 생성 등 로직은 각자 도매인별 테스트 코드를 작성하면서 함께 따로 구현하는게 좋을것같다는 말씀이신거죠?

넵, 맞아요.
각 도메인별 테스트를 작성할 때, 해당 도메인에 맞는 Fixture 클래스를 함께 정의해서 관리하는 방식이 가장 이상적이라고 생각해요.
예를 들어, MemberFixture에서는 createMember()나 createKakaoMemberResponse() 같은 메서드를 만들어두면, 도메인마다 필요한 객체를 의미 있게 재사용할 수 있고, 테스트도 훨씬 쉬워질 것 같아요.

[hisonghy]

Base 클래스 설계가 깔끔하고 공통 설정이 잘 분리되어 있어서 테스트 환경 구성이 편리할 것 같습니다!

다만, 도메인 객체 생성 및 인증 관련 로직까지 Base에서 관리하게 되면 관심사 분리 원칙이 흐려질 수 있어서, 해당 로직은 별도 Fixture 또는 Helper 클래스로 분리하는게 좋을 것 같아요~^^

그럼 도메인 객체 생성 등 로직은 각자 도매인별 테스트 코드를 작성하면서 함께 따로 구현하는게 좋을것같다는 말씀이신거죠?

넵, 맞아요.

각 도메인별 테스트를 작성할 때, 해당 도메인에 맞는 Fixture 클래스를 함께 정의해서 관리하는 방식이 가장 이상적이라고 생각해요.

예를 들어, MemberFixture에서는 createMember()나 createKakaoMemberResponse() 같은 메서드를 만들어두면, 도메인마다 필요한 객체를 의미 있게 재사용할 수 있고, 테스트도 훨씬 쉬워질 것 같아요.

알겠습니다.
주석 지워서 다시 올리갰습니다.
그럼 응답 정보를 파싱해주는 메서드도 없어도 될까요?

[chaiminwoo0223]

알겠습니다.
주석 지워서 다시 올리갰습니다.
그럼 응답 정보를 파싱해주는 메서드도 없어도 될까요?

응답 정보를 파싱해주는 parseResponse 메서드는 남겨두는게 좋을 것 같아요!