8주차 과제 체크포인트

기본 과제

필수

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

선택

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

심화 과제

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

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

피그마 주소

페어팀끼리 각자 해당 테스트 종류별로 어떤 상황에 쓰는지 얘기해보고 이번 프로젝트에는 어떤 테스트 전략이 필요한지 얘기 나눴습니다. 여기서도 "간단한 일정 추가 프로젝트에 E2E는 과하다" 는 의견과 "일정 추가는 사용자가 직접 체험하는 핵심 기능이라 실제 브라우저에서의 동작이 중요하니 E2E해봐도 좋다"는 의견이 나왔습니다. 시각적 회귀 테스트는 논외였습니다.(너무 과함)

• 유닛: 반복일정, 날짜 관련 유틸 테스트 무조건 필요(반대의견 없음)
• 통합: hooks 나 비지니스 로직 검증 필요(반대의견 없음)
• E2E
  • E2E 테스트는 사용자의 실제 경험을 가장 잘 대변하기 때문에, 다른 테스트로는 발견하기 어려운 치명적인 버그를 잡는 데 효과적
  • 제일 핵심적인 플로우를 한번에 검증하는게 좋을거같음
  • (반대) 과하지 않나? 백엔드 측에서 추가한 API에 대한 통합 테스트 반복일정에 대한 수정, 생성, 삭제 정도면 충분
• 시각적 회귀:
  • 전체적인 UI 테스트한번은 필요할 것 같음
  • (반대) 과함. 소규모 프로젝트나 UI 변경이 잦지 않은 경우에는 수동으로 검수하는 것이 더 효율적

---

전체적인 의견을 정리해보면 피라미드 전략이 될거같습니다.. 유닛 많이 통합 적당히 E2E 조금

결론

테스트 전략 논의 및 시나리오 세웠으니 의견 맞는 사람끼리 팀으로 짜거나 개별로 테스트 작성하기

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

이번 프로젝트에서는 통합 테스트와 E2E(End-to-End) 테스트를 병행하는 전략을 선택했습니다. 태영님, 소연님과 함께 통합 테스트 시나리오 3개 중 1개, E2E 테스트 시나리오 3개 중 1개를 각각 선택해 구현하는 방식으로 진행했습니다.

1. 통합 테스트 보완 기존에 작성된 통합 테스트는 주로 개별 기능 단위의 검증에 초점이 맞춰져 있었습니다. 실제 사용 흐름에서 필요한 조합이나 예외 상황을 다룰 수 있도록 보충 시나리오를 직접 작성해 테스트를 추가했습니다.

2. E2E 테스트의 필요성 단위 또는 통합 테스트만으로는 전체 사용자 흐름이나 상태 변화, 뷰 간 전환 등의 맥락을 충분히 검증하기 어렵다고 생각합니다. 특히 이번 프로젝트는 사용자의 연속적인 행동과 일정한 흐름에 따라 작동하는 캘린더 앱이기 때문에, 실제 사용자 경험을 기준으로 한 검증이 필수적이라 생각해 E2E 테스트를 추가했습니다.

결론

통합 테스트는 기능별 정확성을 빠르게 검증하는 데 효과적이며, E2E 테스트는 전체 사용자 경험을 보장하는 데 필수적인 전략이라 생각됩니다. 사용자 경험이 핵심인 캘린더 앱 특성상, 두 테스트 방식이 서로를 보완하며 프로젝트의 완성도를 높여준다고 판단했습니다!

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

!!심화에서 추가된 테스트 코드는 3명 전부 동일하게 작성했습니다.

통합테스트

• 기본 알림 워크플로우
• 뷰 간 데이터 동기화
• form 생성, 수정 플로우

E2E

• 기본 일정 관리: 생성 → 조회 → 수정 → 삭제 전체 플로우
• 뷰 전환: 월/주 뷰 전환 및 날짜 네비게이션
• 검색/필터링

비록 ci에 추가는 못했지만...E2E 통과 인증합니다. (1시간 30분 동안 셋이서 시도했으나 실패했습니다) ci 관련 yaml 파일을 아무리 바꿔도 기존 테스트에 E2E 추가가 안됐습니다...ㅜㅜ

---

과제 셀프회고

이번 과제 할만하다고 생각했는데,, 타임아웃이라는 복병이 터져서 코드를 잘못 짠줄 알고 회귀를 많이했습니다.. 테스트 통과하던 그때로 돌아가자~ 그리고 요구사항 제대로 안 읽었다가 잘못된 기능을 만들어서 다시했습니다.. 난 바보야

지난 주차에 이어 e2e 까지 맛 보면서 이런 생각이 들었습니다.

상황에 맞게 적절하게....TDD는 꽤나 괜찮았다....(근데 시간대비 효율성이 좀..)

기술적 성장

이번에 사용한 커서 룰 : TDD 가이드 지침

• TDD란?

테스트를 먼저 작성하고, 그 테스트를 통과하는 최소한의 코드를 작성하는 개발 방법론

TDD 사이클: Red-Green-Refactor

🔴 Red: 실패하는 테스트 작성 🟢 Green: 테스트를 통과하는 최소한의 코드 작성 🔵 Refactor: 코드 개선 (테스트는 여전히 통과)

기능 만들기에 꽤나 오래 걸리지만 나중에 버그 없이 잘 쓸 수 있었어서 오래 걸린 만큼 안전하다를 체감했습니다.

언제 TDD를 쓰는게 좋을까?

테스트 코드 짜고 고치고 짜고 고치고 반복하는데 시간이 꽤 걸리기에 다음과 같은 상황에서만 해볼까 합니다.

• 복잡한 비즈니스 로직
• 장기 유지보수가 필요한 프로젝트
• 요구사항이 명확한 경우
• 빈번한 수정이 없는 기능(요구사항 변경 시 테스트도 함께 수정해야 되기 때문)

테스트 피라미드(Test Pyramid)

테스트를 유닛 → 통합 → E2E 순서로 쌓아 올린 피라미드 형태로 표현

🔺 구성

• 피라미드 하단 – 유닛(Unit) 테스트
  • 가장 많은 수의 테스트를 작성
  • 실행 속도가 빠르고 작성이 간단해, 작은 단위의 문제를 빠르게 잡아냄
  • 예: 함수가 입력값에 맞는 출력을 반환하는지 검증
• 중간 – 통합(Integration) 테스트
  • 모듈 간 연결과 데이터 흐름을 검증
  • 유닛 테스트보다는 적지만, 시스템 안정성을 위해 꼭 필요
  • : DB에 일정을 저장했을 때 API 응답과 화면 표시가 일치하는지 확인
• 상단 – E2E(End-to-End) 테스트
  • 가장 적은 수의 테스트 작성
  • 실제 사용자 시나리오를 따라가며 전체 흐름을 확인
  • 실행 시간이 오래 걸리고 관리 비용이 크기 때문에 핵심 시나리오에만 집중
  • 예: 로그인 → 일정 생성 → 수정 → 삭제 과정을 전체적으로 검증

아래로 갈수록 실행이 빠르고 비용이 적음. 위로 갈수록 실행이 느리고 비용이 큼 따라서 하단(유닛)에 집중하면서, 꼭 필요한 부분만 상단(E2E)으로 올리는 전략이 좋음!

속도, 안정성, 비용의 균형을 맞추는 최적의 테스트 구조

코드 품질

... 이정도 시나리오면 충분하지 않을까 ㅎㅎ 각자 작성했지만 각자의 레포에서 테코가 성공적으로 돌아갈때 짜릿했던거 같아요

학습 효과 분석

테스트 코드는 있으면 좋다. 그런데 내가 다 짜려면 너무 오래 걸린다.. 나눠서 짜거나 남이 짜주는걸 내가 쓰는게 제일 편하고 좋다...

과제 피드백

E2E 재밌었습니다... 확장프로그램을 알게 되어서 생각보다 편하게 작성을 했는데 이걸 몰랐다면 끔찍했을거 같습니다.. 이미 지난 주차에서 충분히 테스트를 작성했다고 생각되어 반복 일정 테스트 말고 더 추가할게 있을까? 라는 생각도 있었습니다.

리뷰 받고 싶은 내용

• 저희가 CI 에서 e2e 확인해보려고 집단지성을 사용했지만 실패했습니다.. 아무리 바꿔도 안 바뀌더라구요.. 왜 일까요 ㅜㅜ 여러방면으로 시도 해도 안되길래 PR이라 그런가? main에 있는 설정 파일을 따라가는건가 하고 결국엔 포기했는데 성공하신 분이 있더라구요,,!!
• 되던 테스트가 어쩔때는 타임아웃 오류가 떠서 화끈하게 10000으로 늘려서 통과시켰습니다. 이렇게 테스트를 통과시켜도 될까요? 아니면 테스트가 오래 걸리면 문제가 있는것이니 코드를 개선하는게 맞을까요. 타임아웃 이유도 궁금합니다..
• 코치님만의 테스트 팁이 있나요.. 멘토링때 알려주신 palywright CRX 덕분에 e2e 편하게 작성했습니다. 통합 테스트할때는 vitest-preview 덕분에 디버깅하기 수월했구요..혹시 더 있나요? 테스트 꿀팁.. 👀