[5팀 김유현] Chapter 3-2. 프런트엔드 테스트 코드

[yuhyeon99]

8주차 과제 체크포인트

기본 과제

필수

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

선택

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

심화 과제

• 이 앱에 적합한 테스트 전략을 만들었나요?

각 팀원들의 테스트 전략은?

김유현

과제로 주어진 어플리케이션의 규모는 비교적 작다고 생각해서 단위 테스트의 비중이 많은 '테스트 피라미드'전략이 적합하다고 생각해요.

한아름

일정 생성·수정·삭제와 같은 기능 중심 페이지에서는 복잡한 비즈니스 로직보다는 사용자의 주요 시나리오 플로우가 핵심입니다. 따라서 테스트 자원은 통합 테스트(E2E 수준의 흐름 테스트)에 우선순위를 두고, 나머지는 최소화하는 트로피 전략(Trophy Strategy)이 적합합니다.

신희원

캘린더 과제에서 새로운 일정 추가/변경/반복설정/삭제 등 요구사항이 계속 변경되기에, 단위 테스트 비중을 높이는 것보단 통합테스트 비중을 높여서 테스트의 신뢰성을 높이는게 맞다고 생각하여 '테스트 트로피' 전략이 적합하다고 생각합니다.

합의된 테스트 전략과 그 이유는 무엇인가요?

합의된 테스트 전략: 테스트 트로피(Trophy Strategy)선택 이유팀에서 테스트 트로피 전략을 선택한 주요 이유들:

1. 애플리케이션 특성에 적합

캘린더 애플리케이션은 일정 생성, 수정, 삭제와 같은 사용자 중심의 기능 플로우가 핵심

복잡한 비즈니스 로직보다는 사용자 시나리오의 원활한 동작이 더 중요

2. 요구사항 변경에 대한 대응력

새로운 일정 추가, 변경, 반복 설정, 삭제 등 요구사항이 지속적으로 변경되는 환경

통합 테스트는 개별 컴포넌트의 변경보다는 전체적인 사용자 플로우의 안정성을 보장

3. 테스트 신뢰성 확보

단위 테스트만으로는 컴포넌트 간 상호작용에서 발생할 수 있는 문제를 놓칠 수 있음

통합 테스트 중심으로 실제 사용자가 경험하는 시나리오를 검증하여 더 높은 신뢰성 확보

테스트 트로피 전략의 구성

통합 테스트 (Integration Tests): 최대 비중 - 사용자 플로우 중심의 E2E 수준 테스트

단위 테스트 (Unit Tests): 중간 비중 - 핵심 로직에 대한 최소한의 테스트

E2E 테스트: 최소 비중 - 주요 사용자 시나리오에 대한 종단간 테스트

추가로 작성된 테스트 코드는 어떤 것들이 있나요?

한아름님 PR에 테스트 코드 작성하였습니다.(별도로 제 PR에서도 구현했습니다.)

#33

1. 종료일을 지정하지 않았을 때 반복 시작일이 10월 30일 이후이면 시작 날짜에 대한 일정 하나만 생성 (hooks)

작성 이유:

경계값 테스트의 중요성: 10월 30일이라는 특정 날짜 기준의 비즈니스 로직을 검증

예외 상황 처리: 반복 일정 생성 시 발생할 수 있는 특수한 케이스 대응

데이터 무결성 보장: 잘못된 반복 일정 생성으로 인한 데이터 오류 방지

2. 반복 생성된 일정들과 이미 존재하는 일정이 겹칠 때 경고 표시 (integration)

작성 이유:

사용자 경험(UX) 개선: 일정 충돌 상황을 사용자에게 명확히 알려 혼란 방지

실제 사용 시나리오 검증: 반복 일정과 기존 일정 간의 상호작용을 통합적으로 테스트

비즈니스 로직 검증: 일정 충돌 감지 및 경고 시스템의 정확한 동작 확인

3. 반복 일정을 추가할 때 반복 유형이 선택되지 않았을 경우 폼 유효성 검사 (integration)

작성 이유:

사용자 입력 검증: 필수 입력값 누락 시 적절한 피드백 제공

오류 방지: 불완전한 데이터로 인한 시스템 오류 사전 차단

사용자 가이드: 올바른 입력 방법을 사용자에게 안내하여 사용성 향상

---

과제 셀프회고

이번 주에는 여러 시행착오를 통해서 테스트 코드 그리고 MSW와 좀 더 친밀해졌다고 생각합니다.

기술적 성장

• TDD 원칙 심화 학습

  • Red-Green-Refactor 사이클을 실제 코드에 적용하며 각 단계의 중요성을 체득했습니다.
  • 실패하는 테스트(Red)를 명확히 정의하고, 최소한의 코드로 통과(Green) 후, 코드 품질 개선(Refactor)을 반복하여 견고한 개발 방법론을 익혔습니다.

• MSW(Mock Service Worker) 동적 활용

  • handlers.ts 내에서 mockEvents 배열을 동적으로 관리하고, CRUD 요청(GET, POST, PUT, DELETE)을 모의 구현했습니다.
  • 초기 정적 데이터 문제를 해결하기 위해 mockEvents를 가변적으로 관리하여 테스트 환경의 유연성을 확보했습니다.

• 날짜/시간 처리의 복잡성 인지

  • Date 객체 활용 시 월말 처리, 유효하지 않은 종료일 등 엣지 케이스를 디버깅하며 잠재적 오류 지점을 이해했습니다.
  • 반복 일정 생성(generateRecurringEvents) 로직에서 날짜 관련 섬세한 설계 필요성을 체감했습니다.

코드 품질

• 특히 만족스러운 구현

  • saveSchedule 헬퍼 함수 확장 → isRepeating, repeatType 인자 추가로 테스트 코드 간결화.
  • generateUUID 함수 도입 및 mockEvents 배열 동적 관리 → 이벤트 CRUD 테스트의 실제성을 높임.

• 리팩토링이 필요한 부분

  • 테스트 코드 중 act(() => vi.setSystemTime(...)) + await screen.findByText(...) 반복 패턴 → 헬퍼 함수로 추상화하여 가독성 개선 필요.

학습 효과 분석

• 가장 큰 배움

  • 비동기 UI 테스트의 복잡성과 Testing Library의 강력한 기능 체감.
  • findBy*, waitFor, act의 올바른 사용법 학습.
  • MSW 기반 모의 API 관리가 실제 개발 환경에 유용하다는 점 확인.

• 추가 학습 필요 영역

  • React 렌더링 최적화 및 불필요한 리렌더링 방지 기법.
  • 테스트 코드의 가독성과 유지보수성을 높이는 패턴 및 리팩토링 기법.

• 실무 적용 가능성

  • TDD + Testing Library + MSW 기반의 테스트 주도 개발 방식은 실무에서도 유용.
  • 복잡한 비동기 로직과 UI 상호작용 테스트에서 버그 조기 발견 및 안정성 확보 가능.

과제 피드백

• 좋았던 부분
  • TDD 원칙을 과제에 직접 적용 → 요구사항 명확화 및 점진적 구현 경험.
  • 복잡한 비동기 UI 테스트 디버깅 → screen.debug(), screen.logTestingPlayground()

리뷰 받고 싶은 내용

• saveSchedule 헬퍼 함수와 같이 테스트 코드 내에서 반복적으로 사용되는 로직을 추상화하고 재사용성을 높이는 더 좋은 방법이 있을까요?
• generateRecurringEvents 함수에서 repeatEndDate가 없는 경우를 처리하는 현재 로직(과거 날짜일 경우 단일 이벤트만 생성) 외에 "무기한 반복"을 더 명확하고 유연하게 처리할 수 있는 설계 패턴이 있을까요?