[TIL] 원티드 프리온보딩 백엔드 인턴십 Week1) 6일차, 0825

✔️ 오늘 한 일

• yml 프로파일 내 로컬 환경과 테스트 환경 분리
• 게시물 목록 조회 테스트 완료
• 게시물 좋아요 기능 개발 완료
• 게시물 좋아요 기능 테스트 완료
• 게시물 공유 기능 개발 완료
• 게시물 공유 기능 테스트 완료
• 게시물 상세 조회 기능 개발 완료
• 게시물 상세 조회 기능 테스트 완료

👀 오늘의 이슈

1. 테스트 전용 프로파일 분리

• 배경
  • yml 파일 내에 로컬 환경과 테스트 환경의 프로파일 분리가 필요할 것인가에 대해 고민함
• 분석
  • 게시물 목록 조회 테스트 메서드 : A, 게시물 등록 조회 테스트 메서드 : B 라고 가정했을 때,
    게시물 관련 테스트 클래스에는 A와 B가 함께 존재하며, A에는 반환된 게시물의 필드를 검증하는 부분이 있다.
    ex) 게시물의 제목, 내용, ....
    
    이 때, 프로파일을 분리하지 않고 해당 테스트 클래스 전체 실행 시, B보다 아래 라인에 있는 A의 결과가 B의 영향을 받았다.
    (게시물 등록 테스트가 먼저 실행되면서 DB에 새로운 게시물 행이 추가되어 게시물 목록 조회 테스트는 실패하게 된다.)

• 예시) 목록 조회 검증 코드

  Assertions.assertThat(postService.getPosts(pageable).getPostList()).hasSize(3)
                .extracting("title", "content")
                .containsExactlyInAnyOrder(
                        tuple("테스트 제목", "테스트 내용"),
                        tuple("테스트 제목", "테스트 내용"),
                        tuple("망원동 맛집", "맛집 소개")
                );

- 테스트에서 기대하는 게시물 제목 리스트 : "테스트 제목", "테스트 제목", "망원동 맛집"
- DB에 저장되어 있는 게시물 제목 리스트 : "테스트 제목", "테스트 제목", "테스트 제목" `(B로 인해 새로 등록된 게시물)`

• 프로파일을 분리하지 않을 시, 위의 예시처럼 테스트 실행 순서에 영향을 받아 테스트의 검증이 일관되지 않거나, 때에 따라 실패하는 문제가 발생했다.

• 결론
  • 모든 테스트는 테스트 실행 순서에 상관없이 항상 성공해야 하며, 각 테스트 간의 독립성이 보장되어야 한다.
    따라서, 신뢰성 있는 테스트 코드를 작성하고자 yml 파일 내에 local 프로파일과 test 전용 프로파일을 추가하여 로컬과 테스트 환경을 분리했다.

2. @AfterEach의 tearDown() 메서드를 통한 데이터 클렌징 작업

• 배경 : 1번과 마찬가지로, Service 테스트에서 게시물 등록 테스트가 다음 테스트인 게시물 목록 조회 테스트에 영향을 주는 경우가 발생했다.
• 분석 : 각 테스트는 독립적으로 실행되어야 하며, 하나의 테스트가 실행된 후 다른 테스트에 영향을 주지 않아야 한다고 판단했다.
• 결론 : @BeforeEach를 제거하고, @AfterEach의 tearDown() 메서드를 추가하여 각 테스트 후 데이터 클렌징 작업을 수행하도록 했다. 이를 통해 개별 테스트 간에 영향을 방지했다.

3. 공통으로 사용되는 빌더를 별도로 분리하여 리팩토링을 진행함

• 배경 : 게시물 목록 조회 Service 테스트 코드에서 User와 Post를 생성하는 빌더 코드가 반복적으로 작성되었다.
• 분석 : 동일한 객체를 여러 번 생성하는 경우, 객체 생성 코드를 별도로 관리하는 것이 유지보수에 더 효과적이라고 판단했다.
• 결론
  • 공통으로 사용되는 User와 Post를 생성하는 빌더를 별도로 분리하여 코드의 중복을 제거하고 유지보수성을 향상시켰다.

💡 Today I Learned

- 함께 사용하는 코드를 리팩토링하기 위해 설명하는 과정은 쉽지 않다.
상대가 납득할 수 있도록 근거를 들어 글로 잘 정리해보자.