[6팀 이민재] Chapter 3-1. 프론트엔드 테스트 코드#49
Open
minjaeleee wants to merge 37 commits intohanghae-plus:mediumfrom
Open
[6팀 이민재] Chapter 3-1. 프론트엔드 테스트 코드#49minjaeleee wants to merge 37 commits intohanghae-plus:mediumfrom
minjaeleee wants to merge 37 commits intohanghae-plus:mediumfrom
Conversation
This reverts commit 70cadf1.
1. utils - assertDate 함수 수정: 단순 날짜만 비교하도록 수정
1. handlersUtils에 에러 서버 생성 2. 에러처리 테스트 작성
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Medium
7주차 과제 체크포인트
기본과제
Medium
질문
vi.fn()으로 생성된 enqueuesnackbarFn은 토스트 메시지 출력 함수를 모킹한 가짜 함수입니다.
vi.mock(’notistack’, async callbackFn())은 React 알림 라이브러리인 ‘notistack’ 라이브를 테스트 환경에서 동작시키기 위해서 모킹하고, useSnackbar 훅을 모킹합니다. 실제 토스트 UI 대신 enqueueSnackbarFn mock(위에서 설명한 모킹 가짜 함수)를 반환하도록 설정합니다.
대표적인 기능은 아래와 같은 알림 기능을 수행합니다.
테스트에서 실제 토스트 UI를 띄우지 않고도 올바른 메시지가 호출되는지 검증할 수 있습니다.
각 함수들은 MSW로 특정 시나리오별로 API 응답을 모킹하는 역할을 합니다. (CRUD)
- GET /api/events: 초기 이벤트 목록 반환
- POST /api/events: 새 이벤트 추가
- PUT /api/events/:id: 기존 이벤트 수정
- DELETE /api/events/:id: 이벤트 삭제 (성공)
- DELETE 요청 시 500 에러 반환
vi.setSystemTime(new Date('2025-10-01'))를 설정하는 이유는 시간에 의존적인 테스트를 안정적으로 만들기 위함입니다:
시간 고정이 필요한 이유는 캘린더 앱에서는 현재 날짜와 시간에 따라 동작이 달라집니다. 그렇다는건 현재의 환경에 따라 테스트에 영향을 많이 주고, 독립적인 테스트 환경을 제공하지 못하고, 테스트 안정성이 매우 불안합니다.
따라서, setupTests는 모든 날짜 관련 로직을 예측 가능하게 만들고 테스트가 언제 실행되든 일관성 있는 결과를 보장하는 역할을 합니다.
심화 과제
과제 셀프회고
기술적 성장
학습 효과 분석
사실 테스트 코드가 실용적으로 필요한 것인지에 대한 의문을 항상 가지고 있었습니다. 그런데 가장 큰 필요성을 느꼈을 때가 바로 리팩토링 과제 때 였습니다. 저도 이직한 회사에서 입사 3개월 차 쯤에, 번들 시스템 개선과 노드 및 패키지 파일들 업그레이드를 하는 프로젝트를 할 때가 있었는데 그 때는 참 막막했습니다..
아직 내부 기능도 다 모르는데 나한테 이걸 맡기면 내가 어떻게 적절하게 테스트를 해야하지? 라는 의문이 있었습니다. 전체 패키지를 업데이트를 하면 사용하고 있는 라이브러리 내부 모듈에서 함수, 문법, props 등이 바뀔 수 있기 때문에 테스트가 필요했습니다. 결국엔 적절한 방법을 생각하지 못 하고 직접 모든 UI/UX를 테스트 해보았는데요. 이때 테스트 코드가 있었다면 훨씬 안정적으로 프로젝트를 수행할 수 있었을 것 같습니다.
이 테스트 코드 과제 덕분에 안정적이고, 독립적으로 테스트 코드를 작성하는 방법에 대해서 많이 고민해본 것 같습니다. 아직 부족한 점이 많지만 그래도 테스트 코드의 필요성과 장점에 대해서 많이 배웠습니다.
리뷰 받고 싶은 내용
테스트 코드를 안정적이면서 실용적으로 작성하는 방법에 대해서 고민이 됩니다.
테스트 코드를 통해서 예측되는, 기대되는 값을 작성을 하게 되는데 작성을 하다보면 나도 모르게 의도되는 값으로 작성을 하게 될 수도 있을 것 같아요. 특히, 이와 같은 과제(캘린더 앱, 시간 제어 기능)처럼 테스트 단위에 적절한 목 데이터를 작성하게 되면 특히나 더 엣지 케이스에 취약할 것 같은데
어떤 식으로 실무에서 테스트 코드를 계획하고 구성하시는지 알고 싶습니다!