8주차 과제 체크포인트
기본 과제
필수
- 반복 유형 선택
- 일정 생성 또는 수정 시 반복 유형을 선택할 수 있다.
- 반복 유형은 다음과 같다: 매일, 매주, 매월, 매년
- 31일에 매월을 선택한다면 -> 매월 마지막이 아닌, 31일에만 생성하세요.
- 윤년 29일에 매년을 선택한다면 -> 29일에만 생성하세요!
- 반복 일정 표시
- 캘린더 뷰에서 반복 일정을 시각적으로 구분하여 표시한다.
- 아이콘을 넣든 태그를 넣든 자유롭게 해보세요!
- 캘린더 뷰에서 반복 일정을 시각적으로 구분하여 표시한다.
- 반복 종료
- 반복 종료 조건을 지정할 수 있다.
- 옵션: 특정 날짜까지, 특정 횟수만큼, 또는 종료 없음 (예제 특성상, 2025-06-30까지)
- 반복 일정 단일 수정
- 반복일정을 수정하면 단일 일정으로 변경됩니다.
- 반복일정 아이콘도 사라집니다.
- 반복 일정 단일 삭제
- 반복일정을 삭제하면 해당 일정만 삭제합니다.
선택
- 반복 간격 설정
- 각 반복 유형에 대해 간격을 설정할 수 있다.
- 예: 2일마다, 3주마다, 2개월마다 등
- 예외 날짜 처리:
- 반복 일정 중 특정 날짜를 제외할 수 있다.
- 반복 일정 중 특정 날짜의 일정을 수정할 수 있다.
- 요일 지정 (주간 반복의 경우):
- 주간 반복 시 특정 요일을 선택할 수 있다.
- 월간 반복 옵션:
- 매월 특정 날짜에 반복되도록 설정할 수 있다.
- 매월 특정 순서의 요일에 반복되도록 설정할 수 있다.
- 반복 일정 전체 수정 및 삭제
- 반복 일정의 모든 일정을 수정할 수 있다.
- 반복 일정의 모든 일정을 삭제할 수 있다.
심화 과제
- 이 앱에 적합한 테스트 전략을 만들었나요?
각 팀원들의 테스트 전략은?
주제 1: 피라미드 vs 트로피 전략
- 유열: 이미 단위테스트 비중이 높고 통합테스트도 어느정도 있으니 피라미드 구조 유지하자
- 상수: 핵심 E2E만 추가 하면 좋을것 같은데 어떤 E2E를 추가할지에만 집중하자
주제 2: 브라우저 호환성 테스트
- 지수: 브라우저 환경마다 각각 다르게 렌더링될 수 있다는 점에서 E2E의 도입 이점을 이용하자
- 창준: 모달, 캘린더 레이아웃 같은 UI에 하면 좋을듯
- 유열: 모든 브라우저를 테스트하기에는 테스트 시간이 너무 늘어질 것 같고 이번에는 3개 브라우저만 테스트하는걸로 하자
주제 3: 데이터를 변경하는 E2E테스트를 진행할지
- 민지: MSW를 사용하는게 아니라면 realEvents의 데이터를 변경하는 테스트가 되어서 테스트 자체가 격리가 안될듯
- 창준: 데이터를 변경하지 않는 방향으로만 E2E테스트를 사용하자
합의된 테스트 전략과 그 이유는 무엇인가요?
캘린더 프로젝트 테스트 전략
현재 131개 테스트로 견고한 Test Suite 보유. E2E 테스트로 브라우저 호환성을 보강한다.
테스트 피라미드 목표 비율
| 유형 | 목표 비중 | 목적 |
|---|---|---|
| Unit (훅·유틸리티) | 40 % | 비즈니스 규칙을 빠르게 검증 |
| Integration (플로우) | 40 % | 폼 → 훅 → 상태 → UI 데이터 흐름 보장 |
| E2E | 20 % | 실제 사용자 시나리오 및 브라우저 호환 검증 |
E2E 테스트 설계
CRUD 테스트 제외 이유:
- 테스트 독립성 파괴: 일정 추가/수정/삭제로 인한 상태 변경이 다른 테스트에 영향
- 병렬 실행 불가: 여러 브라우저가 동일한 JSON 파일 동시 수정시 Race Condition 발생
- 플래키 테스트 위험: 이전 테스트 실패시 연쇄적 실패, 테스트 순서 의존성 발생
- 통합테스트로 충분: 131개 테스트로 CRUD 로직은 이미 완벽히 검증됨
비파괴적 테스트 선택:
- 상태 변경 없음: 기존 데이터만 읽고 UI 동작만 확인
- 브라우저별 차이: jsdom으로 검증 불가능한 실제 렌더링/동작 확인
- 사용자 경험: 실제 브라우저 환경에서의 UI 인터랙션 검증
핵심 시나리오
E2E-01: 알림 표시
- 테스트: 알림 배지/토스트 표시 확인
- 통합 한계: jsdom에서 실제 타이머 동작, 시각적 알림 표시 확인 불가
- E2E 가치: 브라우저별 타이머, 알림 UI 실제 렌더링 검증
E2E-02: 충돌 모달 인터랙션
- 테스트: 충돌 모달 열기 → ESC로 닫기 → 데이터 불변 확인
- 통합 한계: 모달의 실제 z-index, 포커스 트랩, 스크롤 차단 확인 불가
- E2E 가치: 브라우저별 모달 렌더링 차이 검증
E2E-03: 캘린더 뷰 렌더링
- 테스트: 주간/월간 뷰 전환 → 날짜 표시 확인 → 범위 이동 확인
- 통합 한계: 복잡한 테이블 레이아웃, CSS Grid 실제 렌더링 확인 불가
- E2E 가치: 브라우저별 캘린더 표시 차이 검증
기능별 현재 커버리지
| 기능 영역 | 복잡도 | 현행 단위·통합 커버리지 | 통합테스트 한계 | E2E 테스트 |
|---|---|---|---|---|
| 실시간 알림 | High | ✅ 훅 단위 완료 | ✅ 통합 완료 | jsdom 타이머, 시각적 UI 표시 | E2E-01 |
| 이벤트 충돌 모달 | High | ✅ 단위 (eventOverlap) | ✅ 통합 완료 | 실제 모달 포커스/z-index | E2E-02 |
| 캘린더 뷰 렌더링 | Medium | ✅ 통합 완료 | 복잡한 테이블 레이아웃 렌더링 | E2E-03 |
| 반복 일정 CRUD | High | ✅ 단위 (repeatUtils) | ✅ 통합 완료 | 없음 (충분히 검증됨) | 제외 |
| 검색 기능 | Medium | ✅ 단위 완료 | ✅ 통합 완료 | 없음 (충분히 검증됨) | 제외 |
추가로 작성된 테스트 코드는 어떤 것들이 있나요?
테스트 전략과 함께 기입했습니다.
과제 셀프회고
이번주는 체력적인 이슈로 회고 없이 과제만 제출합니다. 다음주부터 다시 열심히하겠습니다!!
과제 피드백
지수님 수고하셨습니다!
Q. 이번 과제를 통해 비즈니스 로직(날짜 계산, 반복 일정 생성)에서 TDD의 효과를 체감했는데, 실무에서는 기존 레거시 코드베이스에 테스트를 어떻게 점진적으로 도입하는 것이 현실적일까요?
A. 제가 추천하는 방법은 가급적 모킹을 할 필요가 없는 방법을 먼저 사용하는 것을 추천드려요.
두가지 방안이 있는데, 디펜던시가 거의없거나 적은 모듈들을 위주로 테스트 커버리지를 늘려가는 방법과 E2E 테스트만 시작해서 사용자의 크리티컬한 패스부터 중요한 시나리오순으로 커버리지를 늘려가는 방법입니다.
모킹을 많이 사용되게되면 초반에 테스트를 적응하기 전에 너무 많은 피로를 느끼게 될 것 같아요 :)
수고하셨습니다!