단위 테스트 리팩토링

📄 단위 테스트 리팩토링

이 문서는 기존 단위 테스트의 문제점을 개선하고, 예외 케이스를 충분히 검증할 수 있도록 리팩토링한 과정을 소개합니다. 어떤 점을 문제로 인식했고 어떻게 개선했으며, 이 테스트가 실제로 어떤 도움이 되었는지를 기록합니다.

🧩 배경 및 필요성

1. 중복된 Mock 및 하드코딩
   • 날짜/시간을 매번 new Date()로 생성하거나, 각 테스트 케이스마다 Mock 데이터를 중복 선언해 가독성이 떨어지고 유지보수가 어려웠습니다.
   • 하드코딩된 값이 많아, 테스트 간 일관성을 해치고 실수로 인한 오류를 유발할 가능성이 높았습니다.
2. 해피 케이스 중심 테스트
   • 대부분 성공 시나리오만 다루고, 예외 상황이나 경계값 테스트가 부족하여 에러를 조기에 발견하기 어려웠습니다.
   • 실제 운영 환경에서 발생할 수 있는 권한 부족, 올바르지 않은 입력 등은 거의 검증되지 않았습니다.
3. 유의미한 테스트의 필요성
   • 향후 프로젝트에서코드 리팩토링이 및 새로운 인공지능 기능 추가가 예정되어 있습니다.
   • 이를 안정적으로 진행하기 위해선, 중요 로직에 대한 예외 케이스까지 포괄하는 견고한 테스트 세트가 필요했습니다.

🗺️ 문제 해결 과정

1. Mock 데이터 분리 & 재사용성 강화

   • 기존 코드:

     // 테스트 내부에서 직접 Mock 데이터 작성
     repliesRepository.updateBody.mockResolvedValue({
       replyId: 1,
       body: 'Updated reply',
       sessionId: '123',
       ...
     });

   • 개선 후:

     // 공통 mock 파일 (test-replies-service.mock.ts)에 상수화
     export const MOCK_UPDATED_REPLY = {
       replyId: 1,
       body: 'Updated reply',
       ...
     };
     
     // 테스트 코드
     repliesRepository.updateBody.mockResolvedValue(MOCK_UPDATED_REPLY);

   • 결과: 중복을 줄이고, 필요한 곳에서 일관된 Mock 객체를 사용할 수 있게 되었습니다.

2. 날짜 상수화
   • new Date() 또는 '2024-12-02T09:40:17.170Z'와 같은 직접 기재 방식을 개선했습니다.
   • MOCK_DATE 상수를 도입하여 모든 테스트가 동일한 고정 날짜를 사용하도록 수정했습니다.
   • 결과: 날짜 비교 기준이 명확해졌습니다.
3. 네거티브 시나리오(예외 상황) 테스트 강화
   • 다음과 같은 다양한 에러 상황에 대한 테스트를 추가했습니다:
     • 권한이 없는 사용자의 데이터 수정/삭제 시도 시 ForbiddenException 발생
     • 만료된 세션 접근 시 예외 처리
     • DB 제약조건(PK/Unique) 충돌 시 예외 처리
   • 결과: 예외 케이스까지도 커버할 수 있는 테스트가 되었습니다.
4. 테스트 설명의 한글화
   • 예시:
     • it('호스트가 아닌 사용자가 질문을 삭제하려고 하면 ForbiddenException을 발생시켜야 한다')
     • it('이미 좋아요가 있으면 제거하고 liked: false 반환')
   • 테스트의 의도를 명확히 파악할 수 있게 되었고, 팀원 간 소통이 원활해졌습니다.

📈 결과 및 성과

• 개발 효율 및 협업 향상
  • 한글로 작성된 명확한 테스트 케이스로 인해 팀원들이 테스트 의도를 쉽게 이해하게 되었고, CI 빌드 오류도 신속하게 해결할 수 있게 되었습니다.
• 유지보수성 개선
  • Mock 데이터와 상수를 분리하여 코드의 추가 및 수정이 더욱 용이해졌습니다.
• 안정적인 리팩토링 지원
  • RBAC 리팩토링 과정에서 권한 관리 로직이 변경되었음에도, 테스트를 통해 동일한 동작을 보장받을 수 있었습니다.