8주차 과제 체크포인트
기본 과제
필수
- 반복 유형 선택
- 일정 생성 또는 수정 시 반복 유형을 선택할 수 있다.
- 반복 유형은 다음과 같다: 매일, 매주, 매월, 매년
- 31일에 매월을 선택한다면 -> 매월 마지막이 아닌, 31일에만 생성하세요.
- 윤년 29일에 매년을 선택한다면 -> 29일에만 생성하세요!
- 반복 일정 표시
- 캘린더 뷰에서 반복 일정을 시각적으로 구분하여 표시한다.
- 아이콘을 넣든 태그를 넣든 자유롭게 해보세요!
- 캘린더 뷰에서 반복 일정을 시각적으로 구분하여 표시한다.
- 반복 종료
- 반복 종료 조건을 지정할 수 있다.
- 옵션: 특정 날짜까지, 특정 횟수만큼, 또는 종료 없음 (예제 특성상, 2025-10-30까지)
- 반복 일정 단일 수정
- 반복일정을 수정하면 단일 일정으로 변경됩니다.
- 반복일정 아이콘도 사라집니다.
- 반복 일정 단일 삭제
- 반복일정을 삭제하면 해당 일정만 삭제합니다.
선택
- 반복 간격 설정
- 각 반복 유형에 대해 간격을 설정할 수 있다.
- 예: 2일마다, 3주마다, 2개월마다 등
- 예외 날짜 처리:
- 반복 일정 중 특정 날짜를 제외할 수 있다.
- 반복 일정 중 특정 날짜의 일정을 수정할 수 있다.
- 요일 지정 (주간 반복의 경우):
- 주간 반복 시 특정 요일을 선택할 수 있다.
- 월간 반복 옵션:
- 매월 특정 날짜에 반복되도록 설정할 수 있다.
- 매월 특정 순서의 요일에 반복되도록 설정할 수 있다.
- 반복 일정 전체 수정 및 삭제
- 반복 일정의 모든 일정을 수정할 수 있다.
- 반복 일정의 모든 일정을 삭제할 수 있다.
심화 과제
- 이 앱에 적합한 테스트 전략을 만들었나요? 심화과제는 1팀 이의찬, 1팀 김휘린, 5팀 양성진 3명이서 같이 했습니다! 관련 정보는 아래 (5팀 양성진) PR에 적어뒀습니다. https://github.com/hanghae-plus/front_6th_chapter3-2/pull/31
그 외 추가로 작성된 e2e
- 기본 UI 요소들이 정상적으로 표시된다
- 일정 추가/일정 보기 제목 확인
- 월별 뷰 ([data-testid="month-view"]) 표시 확인
- 이벤트 리스트 ([data-testid="event-list"]) 표시 확인
- 검색 입력 필드 표시 확인
- 일정 폼의 모든 입력 필드가 정상적으로 작동한다
- 제목, 날짜, 시작시간, 종료시간, 설명, 위치 입력 테스트
- 카테고리 드롭다운 선택 테스트
- 입력된 값들이 올바르게 저장되는지 확인
- 반복 일정 설정 UI가 정상적으로 작동한다
- 반복 일정 체크박스 활성화
- 반복 유형 선택 (매일, 매주, 매월, 매년)
- 반복 간격 설정
- 반복 종료일 설정
- 반복 일정 미리보기 표시 확인
- 뷰 전환이 정상적으로 작동한다
- 기본 월별 뷰 표시 확인
- 주별 뷰로 전환 ([data-testid="week-view"])
- 월별 뷰로 다시 전환
- 달력 네비게이션이 정상적으로 작동한다
- 다음 달 이동 버튼 ([aria-label="Next"])
- 이전 달 이동 버튼 ([aria-label="Previous"])
- 네비게이션 후에도 월별 뷰 유지 확인
- 검색 기능이 정상적으로 작동한다
- 검색어 입력 기능
- 입력된 검색어 값 확인
- 검색어 지우기 기능
과제 셀프회고
이번 과제는 간단한 기능구현을 TDD로 진행해보는 것이였다.
일단 나는 decribe와 it에 만들어야할 기능의 통합 테스트를 먼저 적었다. 과제가 세부적으로 어떻게 기능을 구현해야하는지 명확해서 작성하는데 어렵지 않았다.
그 다음 AI를 활용해 기능을 구현했는데, 정말 약간의 오류를 제외하고 거의 다 구현했다. 물론 테스트가 통과가 제대로 되진 않았는데, 그건 MUI의 특징과, 명확한 구조를 제대로 파악하지 않고 테스트를 작성한 AI의 실수처럼 보였다.
그래서 해당 케이스들은 직접 수정하고 나니 이번주차는 꽤 빠르게 완료할 수 있었다.
기술적 성장
이번에 Red -> Green 사이클을 실제로 경험해봤다. 뭔가 개발 방향을 더 뚜렷하게 각인 시키면서 개발한다는 느낌이 들었다.
또한 화면에서 해당 요소를 찾기 위해 test id값등을 심어서 사용한다는 꿀팁도 얻었다.
그리고 vitest-preview라는 라이브러리를 잘 사용하게 되었는데, 이 라이브러리는 오류가 나기 직전의 스냅샷을 눈으로 확인시켜줘서 실제로 어떤걸 놓치고 있는지 바로 알게 해줬다. 이 라이브러리를 통해 테스트 오류를 잡아가는데 큰 시간을 줄였던것 같다.
코드 품질
이번 과정에서 코드 자체의 품질이 마음에 들었다 하는 부분은 없었다. 테스트코드를 제외한 기능코드는 100% AI로 구현했고, 나는 테스트만 설계하고 수정했기 때문이다.
그런데 이 과정을 겪어보니 AI의 한계점이 느껴지면서도 잘 사용하는 방법을 잘 알게 된것같다.
최소한의 일은 AI가 굉장히 잘해주니, 그 최소단위의 일들을 테스트등으로 명확하게 뭘해야할지 넘겨주면 큰 일의 단위도 잘 해결해주는 듯한 느낌을 받게되었다.
학습 효과 분석
TDD를 경험하면서 테스트할 기능 명시 -> 테스트 작성 -> 기능구현 -> 검증 이라는 순환구조가 반복되는데, 사실 아직 익숙하지 않은 부분들도 있었다.
내가 만들어야하는 기능의 전체적인부분을 완벽하게 알고있어야 TDD가 좀 더 깔끔하게 진행된다고 느꼈다.
이번 과제에서는 윤년의 조건이라던지, 31일, 등등 다양한 예외 케이스들을 알고 시작해서 크게 문제는 안되었지만, 만약 내가 진짜 새롭게 만드는 기능에 대해서는 저걸 다 이해하고 테스트를 짜놓을수 있을까? 하는 생각이 들었다.
따라서 TDD를 앞으로 더 시도해보면서 내가 단순한 걱정을 하는것인지, 실제 개발에 적합하지 않은지 더 체험해보고 싶다.
과제 피드백
그냥 전체적으로 테스트를 어떤 케이스를 어디까지 만들어야하는가가 여전히 모호했다. 하지만 모호한만큼 이런 과정을 통해 어느정도는 기준을 배워가고있는것같아서 좋았다.
리뷰 받고 싶은 내용
// ✅ 알림도 정상적으로 설정되는지 확인 (시간이 특별해도 알림 작동)
act(() => {
vi.advanceTimersByTime(24 * 60 * 60 * 1000 - 10 * 1000 * 60 - 1000);
});
위 코드로 시간을 24시간 - 10분 을 돌려서 알림이 제대로 동작하는지 확인하려고 했습니다. 그런데 예상과 다르게 토스트알림이 두 개가 발생하는것을 발견했습니다. 여러가지 실험을 해보다보니 10분에서 매 초 더 지날때마다 토스트가 1개씩 더 추가되는것을 확인했습니다. 그래서 임시 방편으로 1초를 제외 시켜보니 토스트 알람이 1개만 뜨게 되었고 테스트는 통과되었습니다. 하지만 이건 어디까지나 테스트를 통과시키기 위해 억지로 끼워맞춘 상태라고 생각합니다..
사실상 10분전에 알림을 '한 번'띄워주면 더 발생하지 않아야 하는데 왜 두 번 발생하는지 잘 모르겠습니다.
useEffect(() => {
const interval = setInterval(checkUpcomingEvents, 1000); // 1초마다 체크
return () => clearInterval(interval);
}, [events, notifiedEvents]);
아마도 알림토스트를 감지하는 인터벌이 1초단위인것과 뭔가 밀접한 관련이 있지 않을까 생각도 들지만,,, 정확한 원인은 파악하지 못했습니다.
근데 실제 코드를 실행하고 알림시간에 도래하면 토스트는 딱 한번만 발생하고 더 나오지 않습니다.
즉 테스트 환경에서만 위 문제가 발생한다는 것인데, 혹시 저 방식의 테스트가 잘못된 것일까요..? 어떻게 알림 시간이 도래되었을때를 테스트 할 수 있을까요..?
과제 피드백
undefined