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()를 반환하도록 추가해두었는데, 혹시 의도된 부분인지 궁금합니다. 아니면 해당 처리를 테스트 내에서 해야 했던 걸까요??
과제 피드백
수고했습니다. 이번 과제는 테스트를 하는 다양한 방법들을 접하면서 테스트 코드를 작성한다라는 그 심리적 장벽을 허물고 친숙해지는데 있었습니다. 회고를 보아하니 잘 수행해준 것 같아요. 잘했습니다!
"정말 색다른 경험이었다... 지금까지 테스트 코드를 실행만 해봤기 때문에 너무 막막하게 느껴졌지만 직접 테스트 코드를 작성해보면서 점점 익숙해지고..." 좋은 변화입니다. 특히나 테스트 코드를 작성하지 못하는 경우가 어렵다기 보다는 그 막막한 느낌 때문에 더더욱 섣불리 하지 못하는데 다행히 이번 과제를 통해서 익숙해졌다니 좋네요. 꼭 그 마지막 벽인 실무에서 한번의 시도를 막막함을 넘어보기를 바래요!
"테스트 코드를 경험해본 사람이 많지 않은 것 같아서 실제 현업에서의 우선순위나 활용 빈도가 뭔가 멀게 느껴지기도 했고..." 맞아요. 실제로 현업에서 테스트 코드 도입률이 높지는 않습니다. 테스크 코드를 작성하는데 들어가는 비용이 적지 않다보니 대개 많이 하지 못하는 실정이지요. 그러다 보면 테스트 코드 도입이 필요한 시점이 와도 관성 때문에 진행하지 못하게 되요. 더군더나 막막함이라는 느낌 때문에 하면 좋겠다 정도로만 생각하고 시도하지 않는 경우도 많구요. 그렇기에 할 수 있다는 것이 더 경쟁력이 될 수 있는 부분이기도 해요. 이런 경험을 해본 것 자체가 큰 자산이 될거에요!
"...리팩토링을 진행하면서 직접 작성한 테스트 코드로 변경 사항을 검증해보니, 테스트가 주는 안정성과 신뢰성을 실감할 수 있었다" 아주 좋네요! 좋습니다.
Q) setupMockHandlerUpdating 내에 존재하지 않는 이벤트를 처리할 시 에러를 반환하는 로직이 없어서 존재하지 않는 이벤트 수정 테스트를 위해 HttpResponse.error()를 반환하도록 추가해두었는데, 혹시 의도된 부분인지 궁금합니다.
=> 아주 좋은 발견이고 적절한 처리였습니다. 실제 API에서는 존재하지 않는 리소스에 대한 요청 시 404나 다른 에러를 반환하는 게 정상이니까요. 테스트 코드도 다른 코드처럼 일단 만들면 버그를 만나고 수정하고 점점 보강해가면서 점점 더 안정적인 코드가 되어 갑니다. 그렇게 추가되다보면 더 현실적인 시나리오에 가까운 테스트 코드가 될거에요.
이번 경험이 현업에서도 이어져서 꼭 하나라도 만들어보면서 그 가치를 지속적으로 확인해보길 바라요. 테스트 코드 경험자가 많지 않다고 하셨는데, 그래서 더 귀한 경험을 쌓은 거라고 생각합니다. 다음 과제도 화이팅입니다!