8주차 과제 체크포인트

기본 과제

필수

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

선택

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

심화 과제

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

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

팀원들의 테스트 전략

이지훈

• 전략: 테스트 트로피 전략
• 핵심 관점: 사용자 관점에서의 정상 동작 확인이 핵심
• 접근법:
  • 통합 테스트 중심으로 사용자 시나리오 검증
  • 훅과 같이 데이터와 상태를 다루는 로직은 단위 테스트로 보완

이은지

• 전략: 테스트 트로피 전략 + Outside-in TDD
• 핵심 관점: 오버엔지니어링 방지와 큰 그림부터 접근
• 접근법:
  • E2E 테스트 → 통합 테스트 → 단위 테스트 → 구현 순서
  • 사용자 시나리오 위주의 통합테스트부터 시작해 점진적으로 구현 범위 축소
• 비율: 단위 20-30%, 통합 50-60%, E2E 5-15%
• 특징: 중요한 단위 로직들은 통합 테스트를 통해 간접 검증 가능

허정석

• 전략: 다이아몬드 형 (단위 테스트 중심)
• 핵심 관점: 빠른 피드백과 비용 효율성 중시
• 접근법:
  • 단위 테스트로 빠른 버그 감지 (UI 컴포넌트, 유틸 함수, 상태 관리)
  • 통합 테스트로 실제 환경과 유사한 검증 (MSW 활용)
  • E2E는 핵심 유저 플로우만 선별적 적용
• 비율: 단위 60-70%, 통합 20-30%, E2E 5-10%

주산들

• 전략: 단위 테스트 중심 + 트로피 (TDD 개발 방식 고려)
• 핵심 관점: TDD 개발에 적합한 점진적 접근
• 접근법:
  • 작은 유닛 테스트부터 시작해 점진적으로 비용이 큰 테스트로 확장
  • Green Zone 진입 후 통합 테스트로 검증
  • 과제의 단일 기능 특성상 유닛 테스트 접근이 용이
• 순서: 유닛 → 통합 → E2E

윤영서

• 전략: 테스트 트로피 전략
• 핵심 관점: 비용 대비 신뢰도의 균형점 추구
• 접근법:
  • 통합 테스트가 핵심: 실제 유저 플로우와 흡사하면서도 구현 변경에 영향 적음
  • 단위 테스트: 저렴하지만 리팩토링 시 취약성 존재
  • 리액트 컴포넌트 간 통합의 중요성 강조
• 참고 자료: Kent C. Dodds의 Testing Trophy 개념

여찬규

• 전략: 단위 테스트 중심의 피라미드 구조
• 핵심 관점: 개발 속도와 비용 효율성 우선
• 접근법:
  • 빠르고 저렴한 단위 테스트 중심
  • 느리고 비싼 E2E 테스트는 최소화
• 비율: 단위 70%, 통합 20%, E2E 10%

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

테스트 트로피 전략

선택 이유

1. 실용적 균형점: 비용 대비 효과를 고려했을 때 통합 테스트가 가장 실용적
   • 사용자 관점의 테스트를 통해 실제 동작 확인 가능
   • 구현 세부사항 변경에 상대적으로 덜 민감
2. 리액트 생태계 특성: 컴포넌트 간 상호작용과 통합이 중요한 프론트엔드 특성 고려
   • 개별 컴포넌트보다는 화면 단위의 사용자 시나리오가 더 중요
   • React Testing Library 등을 활용한 통합 테스트가 효과적
3. 오버엔지니어링 방지: 과도한 단위 테스트로 인한 비효율성 방지
   • 구현이 확정되지 않은 초기 단계에서 과도한 단위 테스트는 비효율적
   • 통합 테스트를 통해 여러 단위 로직을 간접적으로 검증 가능
4. 유지보수성: 리팩토링과 구현 변경에 대한 안정성 확보
   • 인터페이스가 동일하면 내부 구현 변경에 영향을 받지 않음
   • 하나의 테스트로 여러 기능을 동시에 검증 가능

적용 방향

• 통합 테스트 중심: 사용자 시나리오와 주요 플로우 검증에 집중
• 선별적 단위 테스트: 복잡한 비즈니스 로직, 유틸 함수, 훅 등 핵심 로직만 선별
• 최소한의 E2E: 가장 중요한 사용자 여정만 선별하여 적용

이러한 전략을 통해 개발 효율성과 테스트 신뢰성의 최적 균형점을 찾고자 합니다.

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

(작성 필요)

테스트 코드를 작성하지 못 했습니다..... 8주차는 될 줄 알았는데 (정기 상용배포 밉다..) 아쉬움이 많이 남습니다. 그치만 만약 테스트 코드를 작성 했더라면...

기본 과제의 요구사항 항목들을 모두 통합 테스트로 작성을 했을 겁니다. 처음에는 유닛 테스트로 접근했지만 실제 사용자의 관점에서 봤을 때 유닛 테스트로는 한계가 많이 있다고 느꼈고 통합 테스트 코드 작성으로 진행 했을 거 같습니다.

그리고 멘토링 시간에서도 맨 끝 단(리프)는 너무 단순하여 실질적인 테스트의 가치가 낮을 수 있으니 실제 비즈니스 로직이 생길만한 곳 부터 Bottom-up 방식으로 올라가는 방식으로 개발 했을 거 같습니다. 해당 방식으로 리프 컴포넌트에 대해서는 간접적으로도 검증이 가능하다는 판단도 들었습니다.

e2e 도 사용 했을테지만 정말 필요한 부분 한 곳에서만 진행 했을 거 같은데 아직 그 부분(중요한 부분..)은 잘 모르겠어서 기입하지 못 했습니다.

---

과제 셀프회고

너무나 아쉽습니다…. 회사 일정으로 인해 3 챕터인 테스트 코드에 모두 열정적으로 참여하지 못했습니다. 정말 궁금했던 챕터였는데 옾코 챕터였는데 ㅠㅠ…. 그렇지만 한 번도 접해보지 못했던 개발 방식을 아주 살짝이라도 경험해 본 것으로 만족하려합니다. AI 시대에 맞춰 구성을 잘 해주신 거 같아서 좋았습니다. 테스트 코드 뿐아니라 AI 활용법, 접근법에 대해서도 많이 배웠습니다. 한 챕터동안 고생 많으셨습니다. 감사합니다 오프 코치 ♥️

기술적 성장

코드 품질

학습 효과 분석

과제 피드백

테스트 코드 자체를 처음 접해보는 저로서는 되게 새로운 경험이었습니다. TDD 방식으로 과제를 진행 했을 때, 사실 뜬구름(?) 잡는 느낌이 강했습니다. 구현이 안된 것을 먼저 테스트 하라.. 아직도 엄청 와닿는 방식은 아닙니다.

짧게 코드를 작성해 봤지만 Red 단계에서 무조건 코드부터 작성하는 것이 아닌 무엇을 구현할지 또는 어떤 기능이 필요할지에 대해서 생각해보는 시간을 갖고 방향성을 잡고 가는 단계라는 생각이 들었습니다.

Green 단계에서는 해당 방향성을 구체화 하는 시간이고 실제로 구현을 통해 설계의 구체적인 틀이 만들어지는 과정이라 느꼈습니다.

이 과정을 반복한다면 확실히 개발자 측면에서 안정감이 많이 느껴질 수 있겠구나 를 조금이나마 느낄 수 있는 시간이였습니다.

리뷰 받고 싶은 내용