[4팀 김지혜] Chapter 3-1. 프론트엔드 테스트 코드

[adds9810]

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를 활용해 기회가 있어서 좋았습니다. 특히 '질문' 항목 덕분에 무심코 지나칠 수 있는 코드의 의미를 다시 한번 깊이 있게 생각해 볼 수 있었습니다.

리뷰 받고 싶은 내용

1. 현재 setupTests.ts에서 vi.setSystemTime(new Date('2025-10-01'))로 시스템 시간을 10월 1일로 고정하고 있습니다. easy.useCalendarView.spec.ts의 테스트 항목 중 'holidays는 10월 휴일인 개천절, 한글날, 추석이 지정되어 있어야 한다'는 부분이 있는데, 저는 선택한 달의 휴일이 정상적으로 나타나는지 검증하는 것이 중요하다고 판단하여 현재 방식을 유지했습니다. 시스템 시간을 특정 월로 고정하고 해당 월의 휴일을 검증하는 현재 테스트 시나리오가 올바른 접근 방식인지, 혹은 더 효과적인 다른 테스트 방법이 있을지 궁금합니다.
2. 의미있는 테스트 시나리오와 테스트 항목을 잘 작성하는 팁이 있을까요? 있으시다면 궁금합니다.(기준이라던가, 학습 방법이라던가)

[hty0525]

이번 과제도 열심히 하느라 고생하셨습니다!
각 질문에 대해 깊이 고민하고 답변해 주신 게 보이네요.
이번 테스트 코드 과제를 통해 많은 것을 얻어가신 것 같습니다.
AI 의존을 최대한 줄이고, 스스로 할 수 있는 부분을 최대한 해낸 점도 인상 깊었습니다.
기술적 성장 부분에서도 본인이 배운 것들을 명확히 인지하고 있다는 점이 보기 좋습니다.

그리고 질문이 있습니다!

• 테스트 코드를 클린 코드와 연관 지어 생각해 본다면 어떨까요?
• 지혜님이 생각하는 단위, 통합, E2E 테스트란?