[1팀 신희원] Chapter 3-2. 프런트엔드 테스트 코드 🧦

[Amelia-Shin]

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에 테스트 코드 작성하였습니다.
#33

1. 종료일을 지정하지 않았을 때 반복 시작일이 10월 30일 이후이면 시작 날짜에 대한 일정 하나만 생성 (hooks)
작성 이유:
경계값 테스트의 중요성: 10월 30일이라는 특정 날짜 기준의 비즈니스 로직을 검증
예외 상황 처리: 반복 일정 생성 시 발생할 수 있는 특수한 케이스 대응
데이터 무결성 보장: 잘못된 반복 일정 생성으로 인한 데이터 오류 방지

2. 반복 생성된 일정들과 이미 존재하는 일정이 겹칠 때 경고 표시 (integration)
작성 이유:
사용자 경험(UX) 개선: 일정 충돌 상황을 사용자에게 명확히 알려 혼란 방지
실제 사용 시나리오 검증: 반복 일정과 기존 일정 간의 상호작용을 통합적으로 테스트
비즈니스 로직 검증: 일정 충돌 감지 및 경고 시스템의 정확한 동작 확인

3. 반복 일정을 추가할 때 반복 유형이 선택되지 않았을 경우 폼 유효성 검사 (integration)
작성 이유:
사용자 입력 검증: 필수 입력값 누락 시 적절한 피드백 제공
오류 방지: 불완전한 데이터로 인한 시스템 오류 사전 차단
사용자 가이드: 올바른 입력 방법을 사용자에게 안내하여 사용성 향상

---

과제 셀프회고

기술적 성장

새로 학습한 개념

• TDD(Test-Driven Development) 방법론의 실제 적용: Red-Green-Refactor 사이클을 실제 프로젝트에 적용하며, 테스트 작성 → 구현 → 리팩토링의 순환 과정을 체험했습니다.
• MSW(Mock Service Worker)를 활용한 API 모킹: handlers.ts와 handlersUtils.ts를 통해 백엔드 없이도 실제와 유사한 API 환경을 구축하여 테스트할 수 있는 방법을 학습했습니다.
• React Testing Library의 고급 활용: renderHook, act, waitFor 등을 활용하여 비동기 로직과 상태 변화를 안정적으로 테스트하는 방법을 익혔습니다.
• Vitest Preview 도구: 테스트 실행 중 UI를 시각적으로 확인할 수 있는 도구를 도입하여 디버깅 효율성을 높였습니다.

구현 과정에서의 기술적 도전과 해결

• 반복 일정 복잡성 해결: 단일 일정에서 반복 일정으로의 변환, 반복 일정 수정 등 복잡한 비즈니스 로직을 단계별로 구현하고 테스트했습니다.
• 정규표현식을 활용한 테스트 개선: 동적으로 생성되는 ID나 날짜 값들을 정규표현식으로 검증하여 테스트의 안정성을 높였습니다.

코드 품질

특히 만족스러운 구현

• 체계적인 테스트 구조: Unit/Integration/Hooks 카테고리별로 테스트를 체계적으로 분류하여 관리했습니다.
• 재사용 가능한 Mock 헬퍼: setupMockHandlerCreation, setupMockHandlerUpdating 등 테스트 시나리오별 Mock 설정 함수를 구현하여 코드 중복을 제거했습니다.
• 접근성 고려: htmlFor 속성 추가, aria-label 설정 등 웹 접근성을 고려한 코드 개선을 진행했습니다.
• Import 순서 정리: ESLint 규칙을 통해 import 순서를 체계화하여 코드 가독성을 향상시켰습니다.

리팩토링이 필요한 부분

• 단일 및 반복 일정 저장 로직: 커밋 내역에서 보듯이 여러 번의 수정이 있었던 부분으로, 더 명확한 설계가 필요했습니다.
• 테스트 타임아웃 이슈: timeout 값을 증가시키는 임시 방편보다는 근본적인 성능 개선이 필요합니다. (컴퓨터 성능이 문제인지... 잘 모르겠어요)
• 겹치는 일정 확인 방식: 여러 번의 수정을 거쳐 개선되었지만, 초기 설계에서 더 명확한 구조를 잡았다면 좋았을 것입니다.

학습 효과 분석

가장 큰 배움이 있었던 부분

• 실제 TDD 경험: 이론으로만 알고 있던 TDD를 실제 프로젝트에 적용하면서, 테스트가 설계를 개선하고 리팩토링을 안전하게 만드는 효과를 직접 체험했습니다.
• 반복적 개선의 중요성: 커밋 내역에서 보듯이 fix, test, refactor 등의 반복적 개선 과정을 통해 코드 품질이 향상되는 것을 확인했습니다.

추가 학습이 필요한 영역

• 테스트 성능 최적화: timeout 증가로 해결한 성능 이슈를 근본적으로 개선하는 방법에 대한 학습이 필요합니다.
• 복잡한 상태 관리: 반복 일정과 같은 복잡한 비즈니스 로직을 더 우아하게 처리할 수 있는 상태 관리 패턴 학습이 필요합니다.
• E2E 테스트: 현재의 단위/통합 테스트에 더해 사용자 시나리오 기반의 E2E 테스트 도입이 필요합니다.

실무 적용 가능성

• 점진적 기능 개발: 작은 단위로 기능을 구현하고 테스트하는 방식은 실무에서 리스크를 줄이고 품질을 높이는 데 활용할 수 있습니다.
• Mock 기반 개발: MSW를 활용한 API 모킹 전략은 백엔드 개발과 독립적으로 프론트엔드 개발을 진행할 때 매우 유용합니다.
• 코드 리뷰 문화: 테스트 코드가 있으면 코드 리뷰 시 의도를 파악하기 쉽고, 안전한 리팩토링이 가능합니다.
• 품질 관리: ESLint, 접근성 개선 등 코드 품질 관리 방법들을 실무 프로젝트에 바로 적용할 수 있습니다.

과제를 통해 얻은 인사이트

• TDD는 단순히 테스트 작성이 아니라 설계 방법론: 테스트를 먼저 작성하면서 자연스럽게 모듈화되고 테스트 가능한 코드를 작성하게 되었습니다.

과제 피드백

이번에 AI 를 주로 사용했습니다.
커서룰을 추가하여 사용하였습니다.

리뷰 받고 싶은 내용

1. 저는 회사에서 TDD를 사용해본적이 없어서 보통 회사에서 TDD를 작성하는 일이 많은가 궁금합니다. 그리고 개발자만 TDD를 작성하고 테스트하나요? QA팀에서도 사용하는 건지 궁금합니다. (요약 : 회사에서 TDD 사용시 프로세스가 어떻게 되는지 궁금합니다)
2. 이력서에 TDD를 할줄안다! 라고 했을 때 어떤식으로 어필해서 작성하면 좋을까요?