Medium
7주차 과제 체크포인트
기본과제
Medium
- 총 11개의 파일, 115개의 단위 테스트를 무사히 작성하고 통과시킨다.
질문
Q. medium.useEventOperations.spec.tsx > 아래 toastFn과 mock과 이 fn은 무엇을 해줄까요?
toastFn은 알림(토스트 메시지)을 표시하는 함수에 대한 모의(mock) 함수입니다. vi.fn()으로 생성된 이 mock 함수는 실제 알림 UI를 띄우지 않고도 함수가 호출되었는지, 어떤 인자로 호출되었는지 등을 테스트에서 검증할 수 있게 해줍니다. 이를 통해 useEventOperations 훅이 이벤트 추가, 수정, 삭제와 같은 동작 후 사용자에게 적절한 피드백을 주는지 테스트할 수 있습니다.
Q. medium.integration.spec.tsx > 여기서 ChakraProvider로 묶어주는 동작은 의미있을까요? 있다면 어떤 의미일까요?
App 컴포넌트나 그 하위 컴포넌트들이 특정 Context(예: NotificationContext)에 의존하고 있을 가능성이 높습니다. 테스트 환경에서 App 컴포넌트를 렌더링할 때, 실제 애플리케이션과 동일하게 Provider로 감싸주지 않으면 해당 Context를 사용하는 부분에서 오류가 발생합니다. 따라서 Provider로 묶어주는 것은 컴포넌트가 필요로 하는 Context를 주입하여 실제 앱과 유사한 환경에서 통합 테스트를 진행하기 위함입니다. 때문에 의미가 있습니다.
Q. handlersUtils > 아래 여러가지 use 함수는 어떤 역할을 할까요? 어떻게 사용될 수 있을까요?
MSW(Mock Service Worker) 핸들러 내에서 특정 HTTP 요청을 처리하는 로직을 재사용하기 위해 만들어진 것으로 보입니다. 예를 들어, useGetEvents는 이벤트 목록을 가져오는 GET 요청에 대한 응답을 생성하고, useAddEvent는 이벤트 추가 POST 요청을 처리하는 로직을 담당할 수 있습니다. 이 함수들은 handlers.ts 파일에서 각각의 요청 핸들러에 임포트되어 사용되며, 테스트 시나리오에 따라 성공, 실패 등 다양한 응답을 동적으로 생성하는 데 활용될 수 있습니다.
Q. setupTests.ts > 왜 이 시간을 설정해주는 걸까요?
테스트의 일관성과 예측 가능성을 보장하기 위함입니다. vi.setSystemTime을 사용하여 시간을 특정 날짜('2025-10-01')로 고정하는 것을 통해 날짜 및 시간에 의존적인 테스트(예: 이벤트가 오늘 날짜 기준으로 올바르게 표시되는지, 특정 날짜 계산이 정확한지)는 실행 시점의 실제 시간에 따라 결과가 달라질 수 있습니다. 시간을 고정함으로써 테스트는 언제나 동일한 조건에서 실행되어 안정적인 결과를 얻을 수 있습니다.
심화 과제
- App 컴포넌트 적절한 단위의 컴포넌트, 훅, 유틸 함수로 분리했는가?
- 해당 모듈들에 대한 적절한 테스트를 5개 이상 작성했는가?
과제 셀프회고
적어도 기본과제는 ai사용을 줄이고 감이 안 와서 포괄적인 해결 팁을 받아보거나 하늘님이 정리해주신 자료, 검색, 토론하는 자리에 가서 들어보고 해결하려고 노력했습니다(그래서 시간이 더 오래 걸려서 심화는 ai를 활용했습니다.) 기본과제의 일부는 반복적인 부분이 있어서 반복학습으로 어느정도 해결을 했는데 역시 깊이 있는 부분은... 과제 끝나고 꼭 다시 봐야지 생각하게 되는 한 주였습니다.
기술적 성장
vi.setSystemTime을 사용하면 시간에 의존적인 테스트의 예측 가능성을 확보할 수 있다는 것을 알게 되었습니다.- MSW를 이용한 API 모의(mocking)와 이를 활용한 통합 테스트 작성법을 알게 되었습니다.
vi.fn()을 사용해 함수의 동작을 모의하고,toHaveBeenCalledWith와 같은 matcher로 상호작용을 검증하는 방식을 익혔습니다.- toBe, toBeTruthy/toBeFalsy: 과제에서 boolean 값 검증 시 toBeTruthy()나 toBeFalsy()와 toBe()의 차이를 몰라 전자를 사용했는데, 병준님의 회고 덕분에 toBeTruthy()/toBeFalsy()는 truthy/falsy 특성만 확인하여 의도하지 않은 값도 통과시킬 수 있고, toBe(true/false)는 정확한 boolean 타입과 값을 검증하여 더 엄격하고 명확한 테스트가 가능하다는 것을 이해하게 되었습니다.(그리고 수정)
코드 품질
없습니다.ㅜ 심화는 리팩토링에서 시간 부족으로 크게(?) 나눴는데 나중에 잘 보고 나눠야 될거 같습니다;;;
학습 효과 분석
- 가장 큰 배움이 있었던 부분: 테스트 코드를 직접 작성하고 기존 코드를 분석하는 과정에서, 코드의 견고함을 확보하는 테스트의 중요성을 체감했습니다. 특히 반복적인 테스트 작성을 통해 특정 패턴을 익히고 문제 해결 능력을 향상시킬 수 있었습니다.
- 추가 학습이 필요한 영역: React Testing Library의
async유틸리티와waitFor사용법에 대해 더 깊이 학습하여 비동기 테스트를 더 안정적으로 작성하고 싶습니다. - 실무 적용 가능성: 컴포넌트 단위 테스트를 통한 코드 품질 향상과 리팩토링 안정성 확보, 커스텀 훅을 통한 비즈니스 로직 분리와 테스트 가능성 향상이 실무에서 매우 유용하다고 생각하지만, 실제로 적용할 때는 잘 할 수 있을지 모르겠습니다. 이론적으로는 이해했지만 실무 환경에서의 복잡성과 압박감을 고려하면 막막한 부분이 있지 않을까 생각합니다.
과제 피드백
개념으로만 알던 테스트 코드를 직접 경험할 수 있어 좋았습니다. 과제로 제시된 테스트 내용을 기반으로 시나리오를 작성하고 질문의 적절성을 고민하는 과정, 그리고 스스로 테스트 시나리오를 구상하며 다양한 Vitest API, msw를 활용해 기회가 있어서 좋았습니다. 특히 '질문' 항목 덕분에 무심코 지나칠 수 있는 코드의 의미를 다시 한번 깊이 있게 생각해 볼 수 있었습니다.
리뷰 받고 싶은 내용
- 현재 setupTests.ts에서 vi.setSystemTime(new Date('2025-10-01'))로 시스템 시간을 10월 1일로 고정하고 있습니다. easy.useCalendarView.spec.ts의 테스트 항목 중 'holidays는 10월 휴일인 개천절, 한글날, 추석이 지정되어 있어야 한다'는 부분이 있는데, 저는 선택한 달의 휴일이 정상적으로 나타나는지 검증하는 것이 중요하다고 판단하여 현재 방식을 유지했습니다. 시스템 시간을 특정 월로 고정하고 해당 월의 휴일을 검증하는 현재 테스트 시나리오가 올바른 접근 방식인지, 혹은 더 효과적인 다른 테스트 방법이 있을지 궁금합니다.
- 의미있는 테스트 시나리오와 테스트 항목을 잘 작성하는 팁이 있을까요? 있으시다면 궁금합니다.(기준이라던가, 학습 방법이라던가)
과제 피드백
수고했습니다. 이번 과제는 테스트를 하는 다양한 방법들을 접하면서 테스트 코드를 작성한다라는 그 심리적 장벽을 허물고 친숙해지는데 있었습니다. 회고를 보아하니 잘 수행해준 것 같아요.
"적어도 기본과제는 ai사용을 줄이고 감이 안 와서 포괄적인 해결 팁을 받아보거나 하늘님이 정리해주신 자료, 검색, 토론하는 자리에 가서 들어보고 해결하려고 노력했습니다" 좋은 접근이었습니다. 직접 고민하고 찾아보는 과정이 시간은 오래 걸리지만 더 깊은 이해를 가져다주죠. 나중에는 AI를 사용하는것도 고민하고 찾아보는 과정의 도구로 활용하면서도 지금처럼 토론, 자료, 논의, 사유등을 통한 고민들도 함께 해보길 바래요.
"toBeTruthy()/toBeFalsy()와 toBe()의 차이를 몰라 전자를 사용했는데, 병준님의 회고 덕분에..." 아주 좋습니다. 의외로 이렇게 남을 통해서 얻은 지식이 상당히 머리에 잘 남습니다. '잘 모르지만 내가 들은 얘긴데... ' 라는 식의 소문(?)과 같은 소식을 뇌는 잘 좋아하고 잘 기억하니까요. ㅎㅎ 내용적으로 toBe()가 더 엄격한 검증을 한다는 이해가 정확합니다.
"테스트 코드를 직접 작성하고 기존 코드를 분석하는 과정에서, 코드의 견고함을 확보하는 테스트의 중요성을 체감했습니다" 아주 좋습니다. 사실 이러한 내용이 이론적으로 모르는게 아닌데 체감을 한다는게 참 중요하죠. 이번 과제가 그런 역할을 잘 해줬기를 바랍니다.
Q1) 시스템 시간을 특정 월로 고정하고 해당 월의 휴일을 검증하는 현재 테스트 시나리오가 올바른 접근 방식인지, 혹은 더 효과적인 다른 테스트 방법이 있을지 궁금합니다.
=> 현재 접근 방식이 올바릅니다. 시간에 의존적인 테스트는 항상 예측 가능하게 만드는 것이 중요해요. vi.setSystemTime으로 고정하는 것은 좋은 방법입니다.
=> 다만 좀 더 명시적으로 테스트하려면 이런 방법도 있어요. 각 테스트 케이스마다 다른 시간을 설정해서 검증하는 거죠. 예를 들어 "3월로 이동했을 때 삼일절이 나타나는지", "5월로 이동했을 때 어린이날이 나타나는지" 이런 식으로요.
Q2) 의미있는 테스트 시나리오와 테스트 항목을 잘 작성하는 팁이 있을까요?
=> 일단 내가 구현한 내용을 혹은 디버깅을 할때 어떻게 테스트를 하고 있는지를 생각해보세요. 테스트 코드란 인간이 하는 그 일련의 과정을 컴퓨터에게 알아먹도록 코드로 작성하는 행위니까요.
=> 그리고 좋은 테스트 코드는 기획서의 내용(=요구사항)과 일치합니다. 내가 요구사항을 받아서 어떻게 구현을 했고 그 구현이 요구사항에 맞게 만들었는지를 확인하는 그 과정을 테스트 코드화 한다라고 생각해보세요.
=> 이후 엣지 케이스는 이걸 사용자가 모르는 사람이 실행할때 의도치 않은 입력을 한다면 뭐가 있을까 하면서 경계값 테스트를 의식적으로 추가해보세요. 아까 "무엇을 테스트할까?"가 완성이 되었다면 추가적으로 "무엇이 잘못될 수 있을까?"를 생각해보세요. 버그가 발생할 수 있는 지점들을 먼저 찾아보는 거예요.
어쨌건 이러한 고민들이 한번에 잘 만들어야겠다가 아니라 일단 만들어보고 경험해보자는 생각으로 시도하면서 마주하고 풀리게 될 고민들이라 꼭 실무에서 한번 써먹어 보기를 바래요! 다음 주차도 화이팅입니다