[1팀 김휘린] Chapter 3-2. 프런트엔드 테스트 코드

[Hwirin-Kim]

8주차 과제 체크포인트

기본 과제

필수

• 반복 유형 선택
  • 일정 생성 또는 수정 시 반복 유형을 선택할 수 있다.
  • 반복 유형은 다음과 같다: 매일, 매주, 매월, 매년
    • 31일에 매월을 선택한다면 -> 매월 마지막이 아닌, 31일에만 생성하세요.
    • 윤년 29일에 매년을 선택한다면 -> 29일에만 생성하세요!
• 반복 일정 표시
  • 캘린더 뷰에서 반복 일정을 시각적으로 구분하여 표시한다.
    • 아이콘을 넣든 태그를 넣든 자유롭게 해보세요!
• 반복 종료
  • 반복 종료 조건을 지정할 수 있다.
  • 옵션: 특정 날짜까지, 특정 횟수만큼, 또는 종료 없음 (예제 특성상, 2025-10-30까지)
• 반복 일정 단일 수정
  • 반복일정을 수정하면 단일 일정으로 변경됩니다.
  • 반복일정 아이콘도 사라집니다.
• 반복 일정 단일 삭제
  • 반복일정을 삭제하면 해당 일정만 삭제합니다.

선택

• 반복 간격 설정
  • 각 반복 유형에 대해 간격을 설정할 수 있다.
  • 예: 2일마다, 3주마다, 2개월마다 등
• 예외 날짜 처리:
  • 반복 일정 중 특정 날짜를 제외할 수 있다.
  • 반복 일정 중 특정 날짜의 일정을 수정할 수 있다.
• 요일 지정 (주간 반복의 경우):
  • 주간 반복 시 특정 요일을 선택할 수 있다.
• 월간 반복 옵션:
  • 매월 특정 날짜에 반복되도록 설정할 수 있다.
  • 매월 특정 순서의 요일에 반복되도록 설정할 수 있다.
• 반복 일정 전체 수정 및 삭제
  • 반복 일정의 모든 일정을 수정할 수 있다.
  • 반복 일정의 모든 일정을 삭제할 수 있다.

심화 과제

• 이 앱에 적합한 테스트 전략을 만들었나요?
  심화과제는 1팀 이의찬, 1팀 김휘린, 5팀 양성진 3명이서 같이 했습니다!
  관련 정보는 아래 (5팀 양성진) PR에 적어뒀습니다.
  [5팀 양성진] Chapter 3-2. 프런트엔드 테스트 코드 #31

---

그 외 추가로 작성된 e2e

1. 기본 UI 요소들이 정상적으로 표시된다

• 일정 추가/일정 보기 제목 확인
• 월별 뷰 ([data-testid="month-view"]) 표시 확인
• 이벤트 리스트 ([data-testid="event-list"]) 표시 확인
• 검색 입력 필드 표시 확인

2. 일정 폼의 모든 입력 필드가 정상적으로 작동한다

• 제목, 날짜, 시작시간, 종료시간, 설명, 위치 입력 테스트
• 카테고리 드롭다운 선택 테스트
• 입력된 값들이 올바르게 저장되는지 확인

3. 반복 일정 설정 UI가 정상적으로 작동한다

• 반복 일정 체크박스 활성화
• 반복 유형 선택 (매일, 매주, 매월, 매년)
• 반복 간격 설정
• 반복 종료일 설정
• 반복 일정 미리보기 표시 확인

4. 뷰 전환이 정상적으로 작동한다

• 기본 월별 뷰 표시 확인
• 주별 뷰로 전환 ([data-testid="week-view"])
• 월별 뷰로 다시 전환

5. 달력 네비게이션이 정상적으로 작동한다

• 다음 달 이동 버튼 ([aria-label="Next"])
• 이전 달 이동 버튼 ([aria-label="Previous"])
• 네비게이션 후에도 월별 뷰 유지 확인

6. 검색 기능이 정상적으로 작동한다

• 검색어 입력 기능
• 입력된 검색어 값 확인
• 검색어 지우기 기능

---

과제 셀프회고

이번 과제는 간단한 기능구현을 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초단위인것과 뭔가 밀접한 관련이 있지 않을까 생각도 들지만,,, 정확한 원인은 파악하지 못했습니다.

근데 실제 코드를 실행하고 알림시간에 도래하면 토스트는 딱 한번만 발생하고 더 나오지 않습니다.

즉 테스트 환경에서만 위 문제가 발생한다는 것인데, 혹시 저 방식의 테스트가 잘못된 것일까요..?
어떻게 알림 시간이 도래되었을때를 테스트 할 수 있을까요..?