JHeeJinDev 님의 상세페이지 ＞ [6팀 장희진] Chapter 3-2. 프런트엔드 테스트 코드

[6팀 장희진] Chapter 3-2. 프런트엔드 테스트 코드

by JHeeJinDev2025. 8. 25.

8주차 과제 체크포인트

기본 과제

필수

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

선택

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

심화 과제

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

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

페어 2팀 테스트 전략 피그잼 페어 2팀은 팀원들과의 논의를 통해 시스템의 안정성과 신뢰도를 높이기 위해 통합 테스트를 강화하기로 결정했습니다 (작성 필요)

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

이번 프로젝트의 테스트 전략은 테스트 피라미드를 기반으로 수립했습니다. E2E 테스트는 가장 핵심적인 사용자 흐름에만 국한하고, 대부분의 테스트를 모듈 간의 상호작용을 검증하는 통합 테스트에 집중함으로써 효율성과 안정성을 모두 확보하고자 했습니다. (작성 필요)

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

  • 반복 유형별 일정 생성 테스트

    • 매일 반복: 설정된 간격만큼 이벤트 생성
    • 격일 반복: 간격이 적용된 생성
    • 주간 반복: 요일이 일치하는 날짜에만 생성
    • 월간 반복: 시스템 종료일(2025-10-30)까지만 생성
    • 연간 반복: 윤년 2월 29일 처리 (평년에는 건너뛰기)

  • 반복 일정 수정/삭제 테스트

    • 반복 일정 수정 시 단일 일정으로 변경 (repeat.type: 'none')
    • 반복 일정 삭제 시 해당 인스턴스만 삭제

  • 기본 기능 테스트

    • 반복 없음 설정 시 단일 일정만 생성 (작성 필요)

과제 셀프회고

TDD 방법론 적용의 어려움 처음 TDD를 적용할 때 "테스트를 먼저 작성한다"는 개념이 매우 어려웠습니다. 평소에는 기능을 구현하고 나서 테스트를 작성하는 패턴에 익숙했는데, TDD에서는 실패하는 테스트를 먼저 작성해야 한다는 것이 직관적이지 않았습니다. 특히 반복 일정 기능처럼 복잡한 비즈니스 로직의 경우, 어떤 테스트 케이스를 먼저 작성해야 할지 판단하기 어려웠습니다. 매일, 매주, 매월, 매년 반복의 각각의 케이스와 엣지 케이스들을 어떻게 체계적으로 테스트로 작성할지 고민이 많았습니다.

진행 방식:

  • 가장 간단한 케이스부터 시작하여 점진적으로 복잡한 케이스를 추가했습니다. 먼저 "반복 없음" 케이스부터 테스트를 작성하고, 그 다음 "매일 반복"의 기본 케이스, 그리고 점진적으로 "격일 반복", "주간 반복" 등으로 확장했습니다.
  • 기존 테스트 코드 패턴을 참고하여 비슷한 구조로 테스트를 작성했습니다. 특히 medium.integration.spec.tsx의 기존 패턴을 분석하여 repeat.intergration.spec.tsx에 적용했습니다.
  • 테스트 케이스를 우선순위별로 분류하여 핵심 기능부터 테스트하도록 했습니다. 정상 케이스 → 엣지 케이스 → 예외 케이스 순서로 접근했습니다.
  • 현재 e2e 테스트 중 예상치 못한 실패가 발생해 CI 테스트가 실패하고 있는 상황입니다. 문제의 원인을 파악하고 있으며, 빠른 시일 내에 수정하여 테스트를 통과시키는 것을 목표로 하고 있습니다.

리뷰 받고 싶은 내용

이번 과제를 하면서 TDD의 장점(예: 리팩터링에 대한 자신감, 테스트 자동화로 인한 안정감 등)은 이해할 수 있었지만, 동시에 단점도 크게 느꼈습니다. 학습해야 할 것도 많고, 무엇보다 코치님들이 자주 말씀하시는 “실무에 적용해봐라”라는 부분은 솔직히 아직 엄두가 나지 않았습니다.

그래서 궁금한 점은, 코치님이 생각하시기에 TDD는 실무에서 어떤 상황에 적용하는 것이 좋은지입니다. 예를 들어, 시간이 충분히 주어졌을 때라든지, 복잡한 핵심 로직을 다룰 때라든지, 혹은 장기적으로 유지보수가 필요한 서비스일 때라든지 등 어떤 맥락에서 TDD가 가장 효과적이라고 보시는지 알고 싶습니다.

또한 정말 만에 하나, 제가 지금처럼 TDD의 개념만 알고 실제 적용 방식을 잘 모르는 상태라고 했을 때, 이게 이직이나 앞으로의 커리어에 있어서 큰 불리한 점으로 작용하는지도 궁금합니다. 단순히 “알아두면 좋은 스킬” 수준인지, 아니면 “없으면 치명적인 약점이 되는 역량”인지 판단이 잘 안 서서 코치님의 생각을 듣고 싶습니다.

과제 피드백

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

이번 과제를 하면서 TDD의 장점(예: 리팩터링에 대한 자신감, 테스트 자동화로 인한 안정감 등)은 이해할 수 있었지만, 동시에 단점도 크게 느꼈습니다. 학습해야 할 것도 많고, 무엇보다 코치님들이 자주 말씀하시는 “실무에 적용해봐라”라는 부분은 솔직히 아직 엄두가 나지 않았습니다. 그래서 궁금한 점은, 코치님이 생각하시기에 TDD는 실무에서 어떤 상황에 적용하는 것이 좋은지입니다. 예를 들어, 시간이 충분히 주어졌을 때라든지, 복잡한 핵심 로직을 다룰 때라든지, 혹은 장기적으로 유지보수가 필요한 서비스일 때라든지 등 어떤 맥락에서 TDD가 가장 효과적이라고 보시는지 알고 싶습니다. 또한 정말 만에 하나, 제가 지금처럼 TDD의 개념만 알고 실제 적용 방식을 잘 모르는 상태라고 했을 때, 이게 이직이나 앞으로의 커리어에 있어서 큰 불리한 점으로 작용하는지도 궁금합니다. 단순히 “알아두면 좋은 스킬” 수준인지, 아니면 “없으면 치명적인 약점이 되는 역량”인지 판단이 잘 안 서서 코치님의 생각을 듣고 싶습니다.

저는 테스트에 익숙해져야 TDD를 할 수 있다고 생각하고 있어요. 그래서 TDD를 먼저 적용하기보단, 테스트를 먼저 적용하는걸 추천드려요! 다만 TDD는 꼭 코드 뿐만 아니라 다양한 영역에 적용할 수 있답니다! 가령, 회의를 TDD 방식으로 진행할 수 있는데요, "이 회의가 끝났을 때의 우리 상태"를 정의하는거죠. 그리고 그 상태에 도달하기 위한 재료나 질문들을 모아서 진행할 수 있겠죠?

목표를 먼저 정의하고 목표에 도달하기 위한 행동을 하는 것. 이게 저는 TDD 라고 생각해요

그리고 TDD를 모르다고 문제되는건 없답니다 ㅎㅎ 저희 팀에서는 TDD를 하고 있지 않기도 해요. 대신 테스트는 중요하게 생각하고 있어요.

현재 e2e 테스트가 실패하고 있어서... 심화과제는 불합격으로 남겨놓겠습니다!