JiHoon-0330 님의 상세페이지[5팀 이지훈] Chapter 3-2. 프런트엔드 테스트 코드

8주차 과제 체크포인트

기본 과제

필수

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

선택

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

심화 과제

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

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

대부분 통합 테스트를 활용하는 트로피 전략을 선택했습니다.

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

사용자의 경험을 테스트 하기 위해선 통합 테스트와 e2e 테스트가 적합하다고 판단했습니다. e2e 테스트의 경우 비용이 크기 때문에 통합 테스트를 많이 활용하는 것이 적절한 방법이라 합의가 되었습니다.

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

단위테스트

  • 반복 일정을 배열로 변환하는 테스트
  • 반복 일정이 기존 이벤트와 겹치는지 확인하는 테스트
  • 반복 이벤트 저장 테스트
  • 캘린더 날짜 셀 테스트

통합 테스트

  • 반복 일정 추가하기
  • 반복 일정 개별 수정하기
  • 수정 모드에서 반복 설정 숨기기
  • 반복 일정 개별 삭제하기

e2e 테스트

  • crud 테스트
  • 검색어 테스트
  • 캘린터 테스트
  • 일정 알림 테스트

과제 셀프회고

이번주 발제를 들으면서 과거 스냅샷 테스트와 시각적 회귀 테스트를 시도했던 경험이 떠올랐다. 그 당시엔 테스트를 작성해본 경험이 없었고 테스트를 사용하는 많은 회사에서 그런 종류의 테스트를 하는 줄 알았다. 불편한 점이 있어도 원래 그런거 아닐까? 라는 생각을 했던 것 같다. 그러다 결국 테스트를 제거했었다. 상황에 알맞은 기술이 존재한다는 것과 기술의 장단점을 고려하지 못한 경험은 코드를 따라 쳐봤다 수준의 경험이었고, 기억속에서 잊혀졌다. 과거의 이런 경험들을 더 값진 경험으로 만들 수 있는 것이 항해를 하면서 좋은 점이라 생각한다.

기술적 성장

  • 테스트 챕터를 통해 테스트의 종류에 따라 장단점을 생각하게 되었다. 어찌보면 당연하게 생각해야 하는 것이지만, 신경쓰지 않으면 이런 부분을 망각하는 경우가 많은 것 같다.
  • 접근성에 대해 구체적으로 알지 못했는데, 이번에 새로 알게된 부분이 많은 것 같다. 테스트 도구들은 금방 익힐 수 있었지만, 접근성과 관련된 부분에서 많이 헤맨 것 같다.

코드 품질

단위 테스트, 통합(e2e) 테스트의 이점을 활용할 수 있는 구조를 만들고 싶은데, 아직은 익숙하지 않은 것 같다. 버튼 컴포넌트를 예시로 들면, 단위 테스트를 할 때 onClick 이라는 속성에 전달되는 함수를 모킹하고 클릭시 함수가 호출 되었는지 확인 할 수 있다. 통합 테스트에선 버튼을 클릭했을 때 폼 제출과 같이 의도한 동작이 정상적으로 실행 되는지 확인 할 수 있다. 이외 캘린더와 같은 UI 를 테스트한다 가정하면, 단위 테스트는 각 월마다 알맞은 날짜를 생성하는지 통합 테스트에서는 요일이 렌더링 되는지, 1-31 까지 날짜가 표시되는지 확인하는 방법을 사용했다.

학습 효과 분석

  • 상항에 알맞은 테스트를 작성해야 하는 것을 배웠다.
  • 시간과 관련된 부분을 어떻게 다룰 것인지 배웠다.
  • 접근성을 다루는 부분은 아직 익숙하지 않은 것 같다.

과제 피드백

개인적인 경험으론 다른 곳에선 테스트를 작성한다던데 라는 생각으로 접근 했을 때 제대로 된 학습을 경험하지 못했었다. 테스트 챕터를 통해 테스트의 종류와 장단점, 내 상황에 알맞은 테스트는 어떤 것일까를 고민하는 시간을 가질 수 있어서 좋았습니다.

리뷰 받고 싶은 내용

보편적으로 접근성을 활용해 테스트를 진행하는 것이 권장되는 방식이라고 이해했습니다. 하지만 테스트를 직접 작성하면서 접근성을 활용하는 것이 마냥 쉽지만은 않다고 느껴지는데, 그동안 테스트를 작성하면서 이때는 testId 를 사용해야 했다 라는 상황이 있으셨는지 궁금합니다.

과제 피드백

고생하셨어요~ 작성해주신 기능도 잘 동작하고 추가된 테스트도 목적에 맞게 잘 작성된 것 확인했습니다. 꽤 많은 부분을 작성해주신걸 보니 이제 테스트 작성에는 전혀 어려움이 없으신 것 같네요. 반복일정에 대한 테스트도 잘 작성해주셨어요 :+1 해당 테스트에 대한 내용도 ci에 엮어서 함께 테스트 하도록 하는것도 세팅하시면 좋을 것 같네요 ㅎㅎ

보편적으로 접근성을 활용해 테스트를 진행하는 것이 권장되는 방식이라고 이해했습니다. 하지만 테스트를 직접 작성하면서 접근성을 활용하는 것이 마냥 쉽지만은 않다고 느껴지는데, 그동안 테스트를 작성하면서 이때는 testId 를 사용해야 했다 라는 상황이 있으셨는지 궁금합니다.

질문 주셨던 이 부분에서는 쉽지 않다는 것은 저도 잘 알고 있습니다 ㅎㅎ 테스트 작성에서 저도 가장 많은 시간을 쓰는게 쿼링하는 방식을 찾는 거니까요. 하지만 제가 생각하기에는 결국 접근성에 대한 지식이 있어야 하는건 FE개발자에게 필수적이고 학습이 필요한 영역인것은 맞는 것 같아요. Q&A때 말씀드린것처럼 testid는 cypress같이 쿼링을 할 때 요소에 대해 유저 관점으로 접근하기 어려운 상황, 예를 들어서 class 나 id기반 구현 기반으로 접근할 때 구현이 변하면 테스트가 꺠지는 상황이 빈번해지니 그런 상황에 있어서는 testid가 더 나은 선택이다. 이런 결정이 되면 사용하기에 좋은 선택지가 되는거거든요. 절대적인 기준은 없고 구현이 변경될 때 가능한 변하지 않는 명확한 기준인가, 유저 관점의 접근과 비슷한가 관점에서 비교해보면서 사용하면 되지 않을까 싶어요!

고생하셨고 다음주도 화이팅입니다~