7주차 과제 체크포인트

기본과제

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

질문

Q. handlersUtils에 남긴 질문에 답변해주세요.

handlersUtils.ts 파일을 활용하지는 않았습니다.

처음에는 질문에 남겨주신 것처럼, 각 테스트 시나리오별로 핸들러를 생성해주는 유틸리티 함수를 만드는 것을 고민했습니다만 이 코드는 왜 이 위치에 있어야 할까 생각해보니, 오히려 각 테스트가 어떤 API 상태를 필요로 하는지 it 블록 안에서 명확하게 선언하는게 테스트의 의도를 더 직관적으로 보여준다고 느껴졌습니다.

그래서 별도의 유틸리티 함수로 추상화하는 대신에

1. setupTests.ts에서 MSW 서버를 설정하고, afterEach에서 핸들러를 초기화하여 모든 테스트가 항상 동일한 기본 상태에서 시작하도록 보장했고,
2. 이벤트가 하나도 없는 경우처럼 특정 테스트에만 필요한 예외 상황은 해당 it 블록 내에서 server.use()를 사용해 그 테스트만을 위한 핸들러를 일시적으로 덮어씌웠습니다.

덕분에 테스트 코드를 읽는 것만으로도 어떤 테스트가 어느 상황을 가정하는지 한눈에 파악할 수 있었습니다. 복잡도를 다른 파일에 숨기기보다는 각 테스트의 독립성과 명확성을 높이는 이 방식이 보기에도 초기 학습에도 적절하다고 판단했습니다.

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

• 모든 API 요청을 가로채는 핸들러를 작성하여 실제 백엔드 서버 없이도 테스트가 가능하도록 했습니다. 네트워크 상태나 외부 서버의 데이터 변경에 영향을 받지 않는 독립적인 테스트 환경을 조성했습니다.
• setupTests.ts에서 beforeAll, afterEach, afterAll을 사용해 모든 테스트 파일이 실행되기 전에 MSW 서버를 시작하고 각 테스트가 끝날 때마다 핸들러를 초기화하며 모든 테스트가 끝나면 서버를 종료하도록 설정했습니다.
• 통합 테스트에서 useCalendarView와 useNotifications 훅을 모킹했습니다. useCalendarView를 모킹하여 현재 날짜를 '2025-10-15'로 고정했고 테스트 실행 시점에 관계없이 항상 동일한 캘린더 뷰를 보장받게 했습니다.
• useNotifications의 setInterval로 인한 비동기적 동작과 타이머 문제를 피하기 위해 훅 자체를 모킹해 원하는 시점에 특정 알림 데이터를 직접 제공하여 예측 가능하고 안정적인 테스트를 구현했습니다.

심화 과제

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

과제 셀프회고

기술적 성장

• 이전에는 테스트를 기능 검증의 수단으로만 생각했다면 이번 과제를 통해 테스트가 필수적임을 느꼈습니다. 큰 App.tsx를 놓고 팩토링할 때에도 테스트 코드가 있으니 무엇을 변경해도 원래 기능은 보장된다는 느낌은 큰 안정감을 느끼게해줬던 것 같습니다.

코드 품질

• useEventManager 훅을 데이터 조회(Query)와 변경(Mutation)의 책임으로 더 세분화하는 추가 리팩토링이 필요할 수 있겠다는 생각이 듭니다.

학습 효과 분석

• 실무에서 레거시 코드를 개선하거나 신규 기능을 추가할 때 매우 유용할 것같습니다. 이제는 테스트 코드의 존재가 변경에 대한 두려움은 줄이면서 코드의 안정성을 점진적으로 개선하는데에 필수적이라고 생각됩니다.

리뷰 받고 싶은 내용

컴포넌트와 훅을 분리한 다음에 각 계층별로 어떤 테스트 전략을 가져가게 좋을지 궁금합니다. 현재는 아래와 같이 생각하고 있습니다.

• components: testing-library를 이용한 렌더링 및 상호작용 단위 테스트
• hooks: renderHook을 이용한 단위 테스트
• App.tsx: 전체 시나리오를 검증하는 통합 테스트