[1팀 한아름] Chapter 3-1. 프론트엔드 테스트 코드

[areumH]

Medium

7주차 과제 체크포인트

기본과제

Medium

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

질문

Q. medium.useEventOperations.spec.tsx > 아래 toastFn과 mock과 이 fn은 무엇을 해줄까요?

테스트 환경에서의 useSnackbar 함수를 대체한다. 테스트에서 실제로 모달을 띄우지 않고 enqueueSnackbar의 호출 여부와 인자를 검증할 수 있다.

Q. medium.integration.spec.tsx > 여기서 ChakraProvider로 묶어주는 동작은 의미있을까요? 있다면 어떤 의미일까요?

컴포넌트가 필요한 theme, context을 제공하여 정상적으로 렌더링되게 하기 위함이다. useSnackbar 훅도 정상적으로 동작하기 위해서는 SnackbarProvider로 감싸줘야 한다.

Q. handlersUtils > 아래 여러가지 use 함수는 어떤 역할을 할까요? 어떻게 사용될 수 있을까요?

테스트 환경에서 네트워크 요청을 가로채서 목 데이터 응답을 반환하도록 한다. 실제 네트워크 요청 없이 crud 동작을 확인할 수 있고, 목 데이터의 상태를 불러오거나 업데이트할 수 있다.

Q. setupTests.ts > 왜 이 시간을 설정해주는 걸까요?

_test_/hooks/easy.useCalendarView.spec.ts 테스트에서 현재 날짜를 기준으로 계산하기 때문에 시간을 고정해주지 않으면 테스트를 실행하는 날짜에 따라 테스트 결과가 달라질 수 있다.

심화 과제

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

과제 셀프회고

기술적 성장

정말 색다른 경험이었다... 지금까지 테스트 코드를 실행만 해봤기 때문에 너무 막막하게 느껴졌지만 직접 테스트 코드를 작성해보면서 점점 익숙해지고, 코드 안정성과 버그 예방에 중요하다는 걸 체감할 수 있었다. 그런데 테스트 코드를 경험해본 사람이 많지 않은 것 같아서 실제 현업에서의 우선순위나 활용 빈도가 뭔가 멀게 느껴지기도 했고, 실제로 얼마나 활용되고 있는지 궁금해졌다..

코드 품질

리팩토링 과정에서 컴포넌트를 분리하며 일정 폼 관련 로직이 너무 여러 군데에서 사용되어 context 를 사용해 전역으로 사용할 수 있도록 했다. 이미 구현되어있는 훅을 수정하기엔 해당 훅을 테스트하는 코드에 영향이 갈까봐 건들지 못했고.. 그 때문에 각 컴포넌트에 전달되는 props 양이 너무 많아진 것 같다. 리팩토링된 solution 코드가 너무 궁금하다!!!

학습 효과 분석

테스트 환경 전반을 직접 경험해본 것이 가장 큰 배움이었다. 데이터 로딩 실패나 네트워크 오류 같은 다양한 상황을 테스트할 수 있다는 점이 신기했고, 이를 통해 코드가 어떻게 동작하는지 더 명확하게 이해할 수 있었다. 또한, 리팩토링을 진행하면서 직접 작성한 테스트 코드로 변경 사항을 검증해보니, 테스트가 주는 안정성과 신뢰성을 실감할 수 있었다.

과제 피드백

리뷰 받고 싶은 내용

• setupMockHandlerUpdating 내에 존재하지 않는 이벤트를 처리할 시 에러를 반환하는 로직이 없어서medium.useEventOperations.spec.ts 의 존재하지 않는 이벤트 수정 테스트를 위해 HttpResponse.error()를 반환하도록 추가해두었는데, 혹시 의도된 부분인지 궁금합니다. 아니면 해당 처리를 테스트 내에서 해야 했던 걸까요??