7주차 과제 체크포인트

기본 과제

HARD

7주차 과제 체크포인트

기본과제

• 총 11개의 파일, 115개의 단위 테스트를 무사히 작성하고 통과시킨다.

질문

Q. handlersUtils에 남긴 질문에 답변해주세요. 이벤트는 생성, 수정 되면 fetch를 다시 해 상태를 업데이트 합니다. 이를 위한 제어가 필요할 것 같은데요. 어떻게 작성해야 테스트가 병렬로 돌아도 안정적이게 동작할까요? 아래 이름을 사용하지 않아도 되니, 독립적이게 테스트를 구동할 수 있는 방법을 찾아보세요. 그리고 이 로직을 PR에 설명해주세요.

msw 는 기본적으로 server 함수를 사용하여 http 모킹함수를 오버라이딩 할 수 있습니다. 처음의 기본 msw 서버는 기본 값의 handler (get, put, post, delete, patch) 를 사용하고 테스트 코드 상에서 오버라이딩 하여 기본 환경과 다른 환경을 독립적으로 분리해서 사용할 수 있습니다. 이를 통해 기본 환경에서의 다른 기본 데이터와 시간 설정들을 주어서 커스터마이징 할 수 있습니다.

각 테스트가 독립적인 이벤트 데이터와 핸들러 환경을 갖게 하여, 이벤트 생성/수정 등 상태 변화가 외부에 영향을 주지 않도록 구성했습니다. TestEventManager로 각 테스트별 이벤트 상태를 관리하며, server.use를 통해 별도 핸들러를 오버라이드하였습니다. 이로 인해 병렬 테스트 실행 시에도 사이드 이펙트 없이 안정적으로 동작하며, 테스트 간 데이터가 격리되게 됩니다.

리팩토링 전

사실, 최초 개발에는 server.use로 오버라이딩은 하되 특정 http 메서드만 구축하는 것이 아닌 get, post, put, delete 전부를 한 번에 setupMockHandler로 구축했었습니다. put이나 delete를 하기위해서는 필수적으로 get을 해야하는 것이 아닌가? 라는 관점으로 설계한 것이었습니다.

하지만, 과제를 하다보니 메인 환경자체도 setupMockHandler로 설정해놓기도 하며, 의도하는대로는 동작하지만 잘못됨을 깨달았습니다. 사용하지않을 리소스를 사용하기도 하며 테스트 환경임에도 테스트친화적이 적이지 못한 환경이 되어버렸습니다. 하나의 목적성을 두고 작성해야할 코드를 한곳에 여러개를 둔 격이었습니다.

이를 깨닫고 해당 부분을 리팩토링 하여 의도하고자 하는대로 분리하여 교체했습니다.

Q. 테스트를 독립적으로 구동시키기 위해 작성했던 설정들을 소개해주세요.

사실, 설정을 따로 하였는지는 잘 모르겠습니다. 과제를 진행하면서 독립적인 테스트 구동이 아래의 방법을 사용했습니다.

• setupTest 파일에서 기본적인 handler 배열을 두어 기본적인 테스트환경을 구축
• 커스텀한 설정이나 테스트 환경이 필요할 경우에는 handlerUtils에서 생성한 함수를 가져와 새로운 개발환경을 구축
• 개발환경 구축시, 동일한 데이터참조를 위해서 eventManager를 두어 데이터 공유
• 동일한 테스트 환경단위로 묶어서 beforeEach, afterEach 사용

심화 과제

• App 컴포넌트 적절한 단위의 컴포넌트, 훅, 유틸 함수로 분리했는가?
• 해당 모듈들에 대한 적절한 테스트를 5개 이상 작성했는가?

과제 셀프회고

엄마! 나 테스트코드 알게되고 작성도 해봤어!!

기술적 성장

새로 학습한 개념

• vi.useFakeTimers({ shouldAdvanceTime: true })
  • 통합테스트 중에서 다른 테스트와 달리 정말 오랜 시간을 붙잡고 있었던 테스트 코드의 해결법!
  • 기능 :
    • notifications 알람의 기능은 setInterval 함수를 사용하고 있는데, 일정 시간 이내가 되면 알람을 띄워줘야 하는 것.
  • 문제점 :
    • 원하는 시간으로 설정하여 알람메시지를 보기위해 통합테스트에서 useFakeTimers를 사용했다. 하지만, 테스트 환경에서 계속 타임아웃 에러만 뱉어냈다.
  • 해결법 :
    • useFakeTimer내부에 shoutdAdvancedTime 옵션에 true값을 주어, '실제 시간'처럼 시간이 흐르는 것처럼 fake timer가 자동으로 시간 경과를 반영한다.
    • faketimer를 사용하는 곳 보다는 더 상단의 세팅에서 beforeAll 내부에 vi.useFakeTimers({ shouldAdvanceTime: true })을 설정하여 실제 모든 테스트코드 환경에서는 실제 시간처럼 흐르게 할 수 있다!

기존 지식의 재발견/심화

• 작년에 다른 사람 레포지토리를 뒤져가고 독학하면서 써봣던 msw를 다시 써봐서 좋았다!
• 그때에도 이해하기 조금 어려웠지만, 이번 과제를 하면서 오버라이딩을 알게되어서 유익했다. 오버라이딩을 통해 독립적이며 병렬적으로 테스트환경을 구축할 수 있다는 점이 좋았다.
• 테스트 코드는 생각보다 어떤 것을 테스트하고 어떤 범위를 해야하는지 선정하기가 너무 어렵다.

구현 과정에서의 기술적 도전과 해결

• 내 인생에 내 손가락으로 직접 친 테스트코드!! 포기하지 않고 과제하는 것만으로도 기술적인 도전이자 해결이었다.

코드 품질

특히 만족스러운 구현

• 만족스러운 것이..src/__tests__/medium.integration.spec.tsx 통합테스트 코드? 부끄러워서 만족스러운게 없는 것 같습니다. 전부 아쉬워!!

리팩토링이 필요한 부분

• 개인사정으로 과제를 늦게 진행했어서 easy unit test는 개념을 익히면서 할수있는대로 코드를 작성했습니다. 과제를 다하고 시간이 남으면 유닛 테스트 부분을 리팩토링해보고싶다고 생각했는데, 여유가 있지 못했네요.

학습 효과 분석

과제 피드백

• easy에서부터 직접 간단한 유닛테스트 코드를 작성하다가 점점 범위가 넓어지고 describe도 직접 추가하게 되는 학습 방향이 재밌었습니다.
• 통합테스트 중 notifications 테스트 코드 작성하면서 hard를 선택한 것을 무지하게 후회했었는데, 그만큼 많이 고민했어서 좋았습니다! 개인사정으로 시간 투자를 못한것이 아쉬울 따름이네요.

리뷰 받고 싶은 내용