Skip to content

[2팀 박소연] Chapter 3-2 프런트엔드 테스트 코드#32

Open
soyalattee wants to merge 30 commits intohanghae-plus:mainfrom
soyalattee:main
Open

[2팀 박소연] Chapter 3-2 프런트엔드 테스트 코드#32
soyalattee wants to merge 30 commits intohanghae-plus:mainfrom
soyalattee:main

Conversation

@soyalattee
Copy link

@soyalattee soyalattee commented Aug 27, 2025

8주차 과제 체크포인트

기본 과제

필수

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

선택

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

심화 과제

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

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

피그마 주소

페어팀이 모여 각자 유닛, 통합, e2e, 시각적 회귀 테스트를 어떤 상황에 쓰면 좋을지, 과제에서 어떤 테스트가 추가되면 좋을지 얘기 나누었습니다. 그리고 어떤 테스트전략을 가져가는게 좋을지에 대해서도 얘기 나누었습니다.

그 중 이번 과제의 추가 테스트코드에 대해 제일 화두로 논의했던 것은
"간단한 일정 추가 프로젝트에 E2E는 과하다" vs "일정 관리는 유저 입장에서의 실제 브라우저단 동작이 중요하니 E2E를 해봐도 좋다" 였습니다.

그외에 테스트는 필요하며 시각적 회귀 테스트는 과하다가 만장일치였습니다ㅎ.

팀 테스트 전략

팀원들과 토의 끝에 결정된 테스트전략입니다.

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

도은님 PR 발췌


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

통합 테스트와 약간의 E2E 테스트를 병행하는 전략을 선택했습니다.
페어2팀의 멤버중 도은,태영, 소연 이렇게 셋이서 팀을 이루어 진행하였고, 함께 통합 테스트는 큰 시나리오 3개(알림, 달력과 일정 싱크, 일정 등록), E2E 테스트 시나리오 3개 중 각각 선택해 구현하는 방식으로 진행했습니다.

통합테스트로 서비스의 전반적인 기능 검증, E2E 테스트로 기본적인 플로우를 검증하여 사용자 경험 보장할 수 있도록하였습니다.

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

페어2팀의 정도은,이태영,박소연 모두 동일한 테스트코드로 작성되어있습니다.

통합테스트

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

E2E

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

스크린샷 2025-08-29 오전 4 12 23 e2e 성공 이미지

다른분들 PR에도 써있을텐데... CI에 E2E를 추가하고싶은데 못해서 한시간넘게 헤매다가 할 수 없음으로 결론지었습니다. 하지만 영서님(라고 쓰고 구세주라고 부름)께서 방법이 있다고 코멘트 남겨주셔서 추후 적용해보도록 하겠습니다!!

과제 셀프회고

TDD로 개발하기 위해 다음과 같은 방법으로 진행했습니다.

  1. 반복일정 시나리오 정리
  2. 반복일정을 생성하는 순수함수 유닛테스트 작성
  3. 통합테스트 작성
  4. 유닛테스트 성공하는 테스트코드 작성
  5. 통합테스트 성공하는 테스트코드 작성
  6. 구현

이렇게 구현 후 리팩토링하고 끝이 났어야 했으나.. 통합 테스트코드를 잘못짜서 구현 후 통합테스트 수정 -> 리팩토링 순으로 진행되었습니다.
'/event-list' API가 추가되었다는것을 잊고 API 목킹핸들러가 추가하지 않은채 기존 목킹핸들러를 사용해 테스트코드를 작성하였던게 문제였습니다. 그래서 구현 이후 통합테스트의 테스트코드를 재작성하는 과정을 거치게 되었습니다.
API목킹 뿐만아니라 테스트검증 자체도 잘못된 부분이 많아 대부분 갈아엎게 되어.. 이게 TDD가 맞나...? 싶은 과정이였어요
반복일정에 관한 테스트는 유닛테스트케이스 8개, 통합테스트 6개로 총 14개 작성했습니다.

유닛 테스트

expandRepeats 함수에 대한 검증

  • 매일 반복 이벤트를 생성한다.
  • 매주 반복 이벤트를 생성한다.
  • 매월 반복 이벤트를 생성한다.
  • 매월 반복 이벤트 생성 시 31일로 생성할 경우 31일이 없는날은 생성하지 않는다.
  • 매년 반복 이벤트 생성한다.
  • 매년 반복 이벤트 생성 시 윤년 2/29으로 생성할 경우 29일이 없는날은 생성하지 않는다.
  • 종료일 경계 처리한다.
  • 상한일(최대 2025-10-30) 강제한다.

통합 테스트

  • 반복 유형 선택 하여 반복 일정을 생성한다.
  • 월간/주간 달력에 반복 일정 표시(아이콘)가 되어있음을 확인한다.
  • 매일 반복 일정이 여러 개의 인스턴스로 등록된다.
  • 반복 종료(날짜까지)를 확인한다.
  • 반복 일정 단일 수정시 반복아이콘이 사라지고 단일 일정으로 표시되며, 다른 반복 일정은 그대로 유지된다.
  • 반복 일정 단일 삭제시 달력에서 사라지고, 다른 반복 일정은 그대로 유지된다.

반복테스트에서는 기존 제공해주셨던 saveSchedule을 수정하여 saveRepeatSchedule 을 만들어 테스트에 활용했습니다.
그후 심화과제에서는 폼 쪽을 맡게되어 또 반복스케줄 등록 검증도 추가해야해서 saveSchedule 함수를 repeat 값도 받을 수 있도록 변형해서 사용했습니다.

기술적 성장

TDD 로 개발하며 유닛테스트 같은경우는 구현이 더 수월하다고 느꼈습니다. 테스트코드를 작성해두니 AI를 활용할때 구현할 코드를 설명하기도 좀 더 수월했고, 미리 테스트케이스를 짜며 예외케이스들에 대한 고민을 깊게 하고 개발하게되어 내가 짠 코드를 재수정 할 일이 적었습니다.

통합테스트는 심화과제를 위해 팀원들과 시나리오를 같이 작성하고, 분담하여 해결하고 나니 '아, 백지장도 맞들면 낫구나'라고 생각이 들었습니다. 테스트코드가 처음이다보니 헤메는곳도 많고, 실수도 많았는데 함께 통합테스트를 짜며 대화 나누고, 완성하고 나서 코드리뷰를 진행하니 더 좋은 테스트코드방법에 대해서 대화 나누며 더 나은 코드를 짤 수 있었고 같이 고민을 나누고 해결할 수 있어과제도 더 빨리 끝낼 수 있었습니다.

코드 품질

테스트코드위주로 진행된 과제 였는데, 만족스럽게 구현한 곳은 없는것 같습니다 ㅎㅎㅎ..ㅠ
아쉬운 부분은.. 반복일정등록 로직을 추가할때 addOrUpdateEvent 함수에 그대로 if else 처리해서 구현해서 이부분 리팩토링을 해야할것 같습니다.

학습 효과 분석

현재 회사에 QA팀이 없고 기획자와 개발자가 함께 QA를 진행하고 있습니다.
e2e테스트가 준일코치님이 추천해준 Playwrite CRX 사용해서 활용하니 생각!!! 보다 빠르게 작성하게 되어서, 실무에서 필요한 플로우 몇개는 적용해두면 좋을것 같다고 생각했습니다. QA부분을 어느정도 해소할 수 있지않을까라는 생각이 듭니다.

과제 피드백

TDD를 해볼 수 있어 좋았습니다!

리뷰 받고 싶은 내용

@YeongseoYoon-hanghae
Copy link

소연님! 지호님께 e2e ci관련해서 job 트리깅이 되지 않는 문제가 있으셨다고 들어서...! 제꺼 참고차 올려둡니다..! 늦지 않았길 🥹
#7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants