adds9810 님의 상세페이지[4팀 김지혜] Chapter 3-2 프론트엔드 테스트 코드 🦍

8주차 과제 체크포인트

기본 과제

필수

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

심화 과제

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

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

483237434-251cbff3-b63b-486d-8bee-2cbc558184e8 (1)

페어 4팀 테스트 전략 회의실

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

이번 과제에서는 코드의 안정성을 단계별로 튼튼하게 쌓아 올리는 피라미드 테스트 전략을 채택했습니다. TDD로 과제를 진행해야 했기 때문에, 가장 작고 예측 가능한 순수 함수부터 검증하는 단위 테스트로 시작했습니다. 이 튼튼한 기반 위에서, 훅과 컴포넌트 등의 각 부품들이 서로 잘 연결되어 동작하는지 확인하는 통합 테스트를 진행했고, 마지막으로 실제 사용자와 같은 환경에서 전체 시나리오를 검증하는 E2E 테스트로 마무리하며 각 계층이 서로를 보완하도록 설계했습니다.

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

단위 테스트 (Unit Tests):

repeatEventGeneration.spec.ts

반복 일정 생성 시 정확한 날짜 계산이 되는지 확인

  • 매일 반복 시 하루씩 증가하는 날짜 배열 생성
  • 매주 반복 시 7일씩 증가하는 날짜 배열 생성
  • 매월 반복 시 31일이 없는 달은 건너뛰기
  • 윤년 2월 29일 다음 반복은 다음 윤년에만 생성
repeatEventOperations.spec.ts

반복 일정 수정/삭제가 올바르게 작동하는지 확인

  • 하나의 반복 일정만 수정/삭제하기
  • 전체 반복 시리즈를 한 번에 수정/삭제하기
  • API 호출이 성공적으로 이루어지는지 확인
recurringEvents.spec.ts

반복 일정의 모든 주요 기능이 통합적으로 작동하는지 확인

  • 반복 유형별 생성, 수정, 삭제의 전체 플로우 검증

통합 테스트 (Integration Tests):

recurringEvents.integration.spec.tsx

React 컴포넌트들이 함께 연결되어 사용자 입력에 올바르게 반응하는지 확인

  • 반복 일정 체크박스 클릭 시 반복 설정 필드들 나타남
  • 일정 정보 입력 후 저장 버튼 클릭 시 폼 초기화
  • 체크박스 해제 시 반복 설정 필드들 사라짐

E2E 테스트 (End-to-End Tests):

calendar.cy.ts

실제 브라우저에서 캘린더의 모든 주요 기능이 정상 작동하는지 확인

  • 기본 CRUD: 일정 생성, 수정, 삭제의 전체 플로우
  • 반복 일정 기능: 매주 반복 일정 생성, 가상 인스턴스 수정, 원본 삭제
  • 캘린더 뷰: 월간/주간 뷰 전환, 날짜 이동
  • 검색 기능: 키워드로 일정 검색 및 필터링
  • 유효성 검사: 필수 필드 검증, 일정 겹침 처리

과제 셀프회고

8주차를 달려와서 그런가 유난히 집중하지 못했던 과제입니다. 멍해서 더욱 더 판단이 잘 안 섰기에 더디게 진행했고, 급하게 마무리 했습니다. (항해 끝나고 꼭 다시보자 여기..) 그래도 월요일에 팀원들과 함께 나눴던 테스트의 정의나 범위, 테스트 문항을 정리했던게 많이 도움이 되었던 것 같습니다. (그리고 먼저 테스트 길을 닦아주신 소희님, 감사합니다.ㅜㅜ)

기술적 성장

  • 피라미드 테스트 전략: 단위 테스트 → 통합 테스트 → E2E 테스트의 단계별 접근법을 체계적으로 학습했습니다.
  • Cypress E2E 테스트: 실제 브라우저 환경에서 사용자 시나리오를 검증하는 방법을 학습했습니다.
  • React Testing Library: 컴포넌트 테스트에서 사용자 행동 중심의 테스트 작성법을 더 깊이 이해했습니다.

코드 품질

없습니다.

학습 효과 분석

  • 테스트 전략의 중요성: 단순히 테스트를 작성하는 것이 아니라, 어떤 레벨에서 무엇을 검증할지 전략적으로 접근하는 방법을 배웠습니다. 실무에서도 이렇게 단계별로 적용해보면 좋을 것 같습니다.
  • 엣지 케이스 처리: 실제 사용자 시나리오에서 발생할 수 있는 복잡한 날짜 계산 문제를 체계적으로 해결하는 방법을 익혔습니다. 특히 경계값이나 예외 상황을 체계적으로 검증하는 방법은 다른 프로젝트에서도 유용할 수 있을 것 같습니다.
  • Select 컴포넌트 테스트: Material-UI Select와 같은 복잡한 컴포넌트의 테스트 방법(통합테스트 구현시 관련 Select 접근과 관련한 테스트 코드를 작성하고 싶었으나 찾을 수 없다는 에러로 시간을 많이 소비하여 다른 방향으로 구현하게 되었습니다. 차후에 제대로 분석해서 원하는 방향으로 구현해보고 싶습니다.)

과제 피드백

  • 팀 토론을 통한 시야 확장: 팀원들과 함께 테스트의 의미와 범위, 방법에 대해 활발히 논의하면서, 단순히 코드를 검증하는 것을 넘어 테스트 자체의 가치와 철학에 대한 깊이 생각해 볼 수 있었습니다.
  • 실제 사용자 시나리오: E2E 테스트를 통해 실제 사용자 경험을 검증할 수 있었습니다.

리뷰 받고 싶은 내용

  • 피라미드 테스트 전략: 이번 과제에서 단위 테스트 → 통합 테스트 → E2E 테스트 순서로 진행했는데, 실제 프로젝트에서는 새로운 기능을 개발할 때와 기존 코드를 리팩토링할 때의 테스트 전략이 다를까요? 어떤 순서로 테스트를 작성하는 것이 효율적일까요?

과제 피드백

안녕하세요 지혜님! 8주차 과제 잘 진행해주셨네요 ㅎㅎ 고생하셨습니다!!

피라미드 테스트 전략: 이번 과제에서 단위 테스트 → 통합 테스트 → E2E 테스트 순서로 진행했는데, 실제 프로젝트에서는 새로운 기능을 개발할 때와 기존 코드를 리팩토링할 때의 테스트 전략이 다를까요? 어떤 순서로 테스트를 작성하는 것이 효율적일까요?

어떤 코드를 리팩토링 하냐에 따라 다르다고 생각해요! 더 정확히는, 리팩토링의 범위라고 해야하나...

가령 특정 페이지 하나를 리팩토링 할 때는 통합 테스트가 적절할 것이고, 특정 페이지 내부에 있는 자잘한 함수에 대해 리팩토링 할 때는 단위테스트가 적절하겠죠!?

그래서 순서가 중요하다기보단 내가 리팩토링할 범주에 대해 결정이 된다면 이에 대한 테스트 전략을 세우는거죠 ㅎㅎ 상황에 따라 굉장히 달라진답니다!