yunwoo-yu 님의 상세페이지[2팀 유윤우] Chapter 3-2. 프런트엔드 테스트 코드

8주차 과제 체크포인트

기본 과제

필수

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

선택

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

심화 과제

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

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

https://www.figma.com/board/GeKV3mp3GvDSIpB2VN8BQT/2-6%ED%8C%80-%EC%8B%AC%ED%99%94%EA%B3%BC%EC%A0%9C-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%A0%84%EB%9E%B5?node-id=0-1&p=f&t=EyTAVvNrSoCl0LOy-0

피그마를 통해 각자 생각하는 현재 프로젝트에 필요한 테스트 전략들을 작성해봤습니다. 3가지 전략 의견이 나왔습니다.

  1. 통합 테스트 보완
  • 새롭게 추가된 반복일정 기능에 대한 테스트 케이스들을 보완
  • 기본 CRUD, View 데이터 상태, 수정 폼 시나리오 보완
  1. E2E 테스트 추가
  • CRUD 유저 시나리오 기반 테스트 추가
  • 뷰 전환 및 네비게이션 테스트 추가

코드, 툴 같은건 제한을 두지않고 자유롭게 옳다고 생각하는 방향으로 진행했습니다.

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

합의된 전략으로는 우선 통합테스트를 보완하고, E2E 테스트는 선택으로 남겨두었다가 오프코치님의 E2E or 시각적 회귀 테스트 추가를 해보라는 말을 듣고 E2E 시나리오 1개까지 하는걸로 추가되었습니다.

저는 캘린더 앱에 E2E 테스트까지는 너무 과하다는 의견을 제시했는데요,

현재 캘린더 앱은 간단한 CRUD API를 통한 1개의 페이지 앱으로 되어있으므로 통합테스트만으로 충분히 컨트롤이 가능하다고 생각했고, E2E 테스트 같은 상위 레벨의 테스트는 복잡도 대비 얻는 이점이 크지 않다고 판단했습니다. 하지만 팀의 합의와 코치님의 조언을 받아들여 최소한의 E2E 시나리오 1개를 추가하는 것으로 결정했습니다.

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

  1. 통합테스트
  • 반복 일정에 대한 테스트 케이스 추가
  • 알림 기능 테스트 보완
  1. E2E 테스트 (cypress)
  • 유저가 하루 일정에 대해 추가하고, 수정, 삭제하는 시나리오 추가

과제 셀프회고

TDD는 생각보다 많이 어려웠습니다.. 항상 우선 기능을 만들고 보완하는 방식으로 개발을 해왔는데 반대로 많은 가능성들을 고려한 상태로 테스트를 작성하고 기능을 만들어가는 과정이 쉽지 않은 것 같습니다.. 테스트 챕터를 진행하며 프론트엔드에서의 테스트에 대해 굉장히 긍정적인 방향으로 생각이 바뀌었지만 TDD는 ㅎㅎ... 흠.... 아직 저에겐 어려운 부분인 것 같습니다.. 이번 과제는 3일정도를 개인적인 사정이 있어 거의 진행하지 못했다보니 아쉬움이 많이 남는 것 같습니다!

기술적 성장

  • cypress를 통한 E2E 테스트 작성 경험
  • 테스트 코드 문법에 대한 학습

과제 피드백

심화에 대한 조금 더 명확한 제시가 있었으면 좋겠습니다! 전략을 정할 때 현재 프로젝트에서 필요하지 않다고 생각하지만 과제를 위해서 추가를 어느 부분까지 해야할 지 헷갈렸습니다!

리뷰 받고 싶은 내용

  1. 대표적인 e2e 테스팅 툴로 cypress, playwright가 있는 것 같습니다! 실무에서는 주로 어떤 툴을 사용하며 사용하는 이유는 무엇인지 궁금합니다!

  2. e2e 테스트를 작성할 때 유저시나리오 기반으로 작성을 해보려 노력했습니다. 근데 작성하다보니 통합테스트로 충분히 커버가 되는 부분들이지 않나? 라는 생각이들었습니다. 실제 프로덕트에서 e2e 테스팅은 어떤 경우에 사용하시나요?

과제 피드백

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

대표적인 e2e 테스팅 툴로 cypress, playwright가 있는 것 같습니다! 실무에서는 주로 어떤 툴을 사용하며 사용하는 이유는 무엇인지 궁금합니다!

사실 저는 실무에서 써본적이 딱히 없긴 한데... 아마 쓴다고 치면 playwright을 사용할 것 같아요 ㅎㅎ 관리하기도 쉽고 작성하기도 쉽다보니.. 특히 playwright crx 확장프로그램을 사용하면 테스트를 뚝딱뚝딱 만들 수 있답니다 ㅋㅋ

e2e 테스트를 작성할 때 유저시나리오 기반으로 작성을 해보려 노력했습니다. 근데 작성하다보니 통합테스트로 충분히 커버가 되는 부분들이지 않나? 라는 생각이들었습니다. 실제 프로덕트에서 e2e 테스팅은 어떤 경우에 사용하시나요?

순수하게 비즈니스 로직에 대한 부분은 통합 테스트로 충분히 커버할 수 있다고 생각해요 ㅎㅎ 다만 디바이스마다 브라우저마다 관리해야 하는 로직이 다르다거나 실제로 화면에서 보여지는 것들에 대한 검증을 해야할 때는 e2e 가 필요하다고 생각해요.

그리고 통합테스트의 경우 e2e 보다 작성하는게 더 어려울 수 있어요. 그래서 빠르게 작성해서 검증 해야 할 때는 e2e가 효과적이라고 생각합니다!