8주차 과제 체크포인트

기본 과제

필수

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

선택

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

심화 과제

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

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

사실 저희 페어2팀은 전체적으로 테스트코드를 처음 접하신 분들이 많았습니다. 그렇기 때문에 테스트의 종류에는 어떤 것이 있는지 서로 이야기를 나누었고, 이번 과제에서 기본 과제를 넘어서 어떤 테스트를 진행하면 좋을지에 대해 나눴습니다. 단순히 어떤 테스트를 하는지 보다는 왜 그 테스트가 하고싶은지 까지 이야기를 나누었습니다.

팀원 들의 의견을 정리하여 나열하면 아래와 같습니다.

• 유닛테스트와 통합테스트를 촘촘히 작성하여 e2e 테스트의 횟수를 줄이자
  • 단일 페이지의 단순 CRUD 기능만있는 캘린더 앱이라면 e2e 테스트가 필요한 것인지에 대한 의문
  • 반복 일정 계산, 날짜/시간 처리, 일정 충돌 검사, 필터링/검색 과 같은 계산에 관련된 것은 유닛테스트로 진행할 것
• e2e 테스트를 통해 실제 브라우저 환경에서 발생할 수 있는 사용자 시나리오를 테스트
  • 다른 테스트보다 더 큰 리소스가 소비되는 e2e 테스트의 갯수를 줄이되 정말 중요한 요소를 테스트 할 것
• 시각적 회귀 테스트의 경우에는 UI를 매치시켜 테스트를 진행하는 것으로, CRUD가 주인 캘린더 앱에서는 알맞지않은 것으로 판단

이를 정리하니 다수의 팀원이 테스트 피라미드/ 트로피를 기반으로 테스트 전략으로 보입니다!

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

• 유닛테스트 : 현재 클라이언트 단에서 반복일정을 계산하며 일정을 저장하는 것을 기준잡아서, 이를 유닛테스트 비율을 높혀 진행
• 통합테스트 : 단순한 기능단위의 유닛테스트에서는 사용자 인터렉션에 대한 검증이 부족하고, 리소스가 많이 들어가는 e2e 보다는 통합테스트를 진행
• e2e : 단, 캘린더 앱의 코어기능인 일정에 대한 CURD와 뷰의 변화를 e2e를 통해서 사용자 시나리오 확인

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

• e2e 테스트
  • CRUD, 뷰의 변화
• 통합테스트
  • 반복일정에 대해서 뷰에서는 날짜마다 갯수를 보여주되, 리스트에서는 하나의 이벤트로 보여주는 테스트
• 유닛테스트
  • 클라이언트에서 계산하는 반복 일정을 뷰에 보여주기위해 그룹화 시키는 함수
  • 반복되는 일정을 날짜 배열로 만들어주는 함수 (+경계값 테스트)

---

과제 셀프회고

사실 시작도 못할 뻔

아 TDD 재밌었는데 시작하기가 너무 어려웠습니다. ㅠㅠ! 지금 생각해도 조금 웃긴데, 어떤 부분을 먼저 헤야할지 감이 오지않아서 클로드와 퍼블렉시티를 무척이나 많이 괴롭혔어요. "이런 프로젝트와 이런 요구사항이 있는데 TDD를 하려면 어떻게 해야할까?" 되게 상투적이면서도 저의 궁극적인 궁금증이었어요.

이게 또 웃긴게 물어볼 때마다 대답이 달랐었습니다.

• 기본적인 기능과 ui가 있으니 통합 테스틑 부터 만들어 보는 건 어떠니
• 반복 일정에 대한 유틸함수에 대한 유닛테스트먼저 만드는건 어떠니

아니, 지금 생각해도 신기하긴하네요. TDD는 작은것부터 점차적으로 개발해나간다고 알고있는데 유닛보다 통합을 이야기 꺼낼거라고 생각도 못했거든요.

물론, 고민고민하고 여러곳에 물어보고하다가 시작은 해야하니 정석대로 반복 일정의 날짜배열을 만드는 함수 유닛테스트를 작성하며 과제를 시작했습니다.

TDD...

처음에는 TDD의 RED > GREEN 순서로 진행하다가, 나중에는 테스트만 작성해도 GREEN이 바로 되는 것을 경험했습니다. 이전의 테스트 단계에서 오버엔지니어링을 한걸까? 테스트 코드의 순서를 잘못 지정한걸까? 생각이 들었는데, 아마 전자인거 같습니다. ㅎ

정말 나중에는 테스트코드를 작성해두고 구현과 함께하면서 테스트코드를 수정하는 경우도 있더라구요. 이게 맞나 싶었지만, 과제열차는 멈추지 않아야하니 칙칙폭폭 갔습니다.

커밋메시지 꾸며주고 싶어서 RED > GREEN 열심히 맞춰봤네요. 커꾸...ㅎ 포스푸쉬 되어있는 이유는.....커밋꾸미기 때문입니다 ㅎ

폴더 정리

사실 파일 만들고 코드 작성한 건 적지만, 테스트 코드 작성 할 때마다 폴더구조랑 파일이 신경쓰이더라구요. medium, easy로 놔두는것이 맞을까? 라는 생각을 했습니다. 역할로도 레이어로도 분리되지 않은 것에 불편함이 들어서 테스트 폴더구조와 파일이름도 변경해주었습니다.

src/__tests__/
├── unit/                              🔵 단위 테스트 (17개 파일 중 7개)
│   ├── apis/                          📡 외부 API 호출
│   │   └── fetch-holidays.spec.ts     
│   └── utils/                         🛠️ 순수 함수/유틸리티
│       ├── date-utils.spec.ts         
│       ├── event-overlap.spec.ts      
│       ├── event-utils.spec.ts        (getFilteredEvents + groupRepeatingEvents)
│       ├── notification-utils.spec.ts 
│       ├── repeat-utils.spec.ts       
│       └── time-validation.spec.ts    
├── hooks/                             🎣 React 훅 테스트 (4개)
│   ├── calendar-view.spec.ts          
│   ├── event-operations.spec.ts       
│   ├── notifications.spec.ts          
│   └── search.spec.ts                 
├── integration/                       🔗 컴포넌트 통합 테스트 (2개)
│   ├── event-management.integration.spec.tsx
│   └── repeat-events.integration.spec.tsx
└── e2e/                              🌐 E2E 테스트 (3개)
    ├── basic-functionality.e2e.spec.ts
    ├── event-operations.e2e.spec.ts
    └── user-interface.e2e.spec.ts

아쉬운 점

시작을 어떻게 하지~라면서 시간을 허비하고, 과제 제출 날에 다가와서는 야근을 하게되면서 나는 이번에도 시간분배를 못했구나 깨달았습니다. (8주차인데요? ㅎ;) 서버로직은 클라이언트로 가져와야하는 순간부터 유닛테스트를 더 많이 해야겠다는 생각은 들었습니다. 하지만, e2e를 줄이고 현재 작성된 통합테스트를 더 늘려야겠다 라는 생각은 실천에 옮기진 못했습니다. ㅠㅠ 심화과제도 결국 e2e와 유닛에 좀 더 치우쳐 작성하게 되었습니다.

---

기술적 성장

과제 포기하지 않은 나, 칭찬 해

코드 품질

구린내가 나요

학습 효과 분석

• 통합테스트는 분리하면 분리할 수록 리소스가 많이 들어서 테스트 완료 시간이 늦춰진다. (맞는가? 모르겠다.)
• 아, 테스트 코드작성하는 것도 TDD도 재밌다. 그런데 너무 어렵다. 오프코치님께 받은 강의 열심히 보고 회사에 도입해야지

추가 학습이 필요한 영역

아, e2e랑 시각적 회귀테스트...

실무 적용 가능성

회원가입로그인+온보딩 로직에 기능을 추가한적이있습니다. 그때, 테스트 코드가 없었으며 발생할 수있는 케이스는 족히 20가지가 넘었습니다. (이 작은 서비스에..흠;) 아무튼, 그래서 개발 및 수정작업을 진행하면 해당 케이스를 직접 손수 진행했었어요. PM이랑 저랑 둘이서요. 진짜 슬프게도 회원가입에 전화번호 인증도 있고 소셜로그인도 있어서, 정말 많은시간을 들였습니다.

테스트코드가 정말 절실하더라구요. 하지만, 그때의 저는 테스트 코드의 테도 몰랐습니다 ㅠㅠ 도전하고싶어도 여유가 되지 못해서 공부하지도 못했었거든요. 항플을 통해서 테스트 코드에 친숙해지고, 과제 질문하다 얼떨결에 받은 테코강의도 생겨서 너무 든든합니다. 사실 준일님 멘토링 듣자마자 디자인시스템에 테코 언제넣을까 신나있었거든요. 근데 또 마침! 그 다음날 앱개발자가 웹어드민을 하면서 라이브러리 교체하니깐 테코를 넣겠다고 했어요. 흰 눈밭을 먼저 밟아주더라구요.

저에게는 7~8주차가 정말 실무 적용하기 좋은 주차인것 같습니다!

과제 피드백

• 심화과제의 요구사항을 명시적으로 기재해주셨으면 좋겠습니다!
• 과제 요구사항이 조금 모호해서 뉴비 개발자인 저에게는 좀 많이 힘들엇던 것 같아요.
• 그래도 다음에도 또 해보고 싶은 과제였습니당

리뷰 받고 싶은 내용

• 통합 테스트가 medium.intergration 으로 시작하는 파일명을 갖고 있어서 역할에 맞게 파일로 분리 하고싶었습니다. 그런데 분리하고보니 테스트 속도가 현저히 지연되어 타임아웃도 발생하기도했습니다. 통합테스트의 경우는 한 파일에 모아 두고 작성하는 편인 걸까요? 아니면 현재 msw 세팅을 제대로하지 않아서 지연이 발생하고 있는 것 일까요?

• 질문 있습니다! TDD를 하다보니 명확하게 내가 무엇을 만들어야겠다는 것이 명시하고 그것을 놓치지 않고 만들 수있는 장점을 느꼈습니다. 디자인시스템 컴포넌트가 확장성도 있지만, 명세에 기재된 기능들을 만족하여 구현해야하는 상황이라면 TDD 방식이 좋지 않을까 생각했습니다. 그럴까요..? 그런가? 디자인시스템 컴포넌트를 만들때 기능을 누락하거나 누락시키는 것을 종종 봐왔던 터라 TDD를 하면 미연에 방지할 수 있지 않을까, 라는 생각이 들었습니다. 어떻게 생각하시나요!?!