8주차 과제 체크포인트

기본 과제

필수

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

선택

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

심화 과제

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

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

Given-When-Then BDD 전략 사용

• Given: 테스트의 전제 조건과 초기 상태를 명확히 정의합니다.
• When: 테스트하고자 하는 구체적인 동작이나 이벤트를 기술합니다
• Then: 예상되는 결과나 상태 변화를 명시합니다.

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

BDD(Given-When-Then) 전략을 선택한 이유:

1. TEO 코치님으로 부터 배운 테스트 방식이기도 하고,
2. 이해하기 쉬워서 팀원들이 테스트 의도를 명확하게 파악 가능하고,
3. 비즈니스 요구사항과 직접적으로 연결되 명세를 파악하기 쉽고,
4. TDD Red-Green-Refactor 사이클과 유사한 방식으로 진행할 수 있어서 선택하였습니다!

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

반복 일정 기능 관련 TDD 테스트 (src/__tests__/unit/repeatEvent.spec.ts)

1. 31일 기준 매월 반복 처리

   • 31일이 없는 달은 제외된다

2. 윤년 2월 29일 매년 반복 처리

   • 평년에는 해당 날짜가 생성되지 않는다

3. 반복 종료 조건 처리

   • 특정 날짜까지 종료 조건이 적용된다
   • 특정 횟수만큼 종료 조건이 적용된다

4. 반복 간격 계산

   • 매일 반복에 2일 간격이 적용된다
   • 주간 반복에 2주 간격이 적용된다

5. 반복 일정 전체 조작

   • 반복 일정 전체 수정 시 모든 관련 일정이 업데이트된다
   • 반복 일정 전체 삭제 시 모든 관련 일정이 제거된다

6. 예외 날짜 처리

   • 반복 일정 중 특정 날짜가 제외된다
   • 예외 날짜가 없으면 모든 반복 일정이 생성된다

총 10개의 새로운 테스트 케이스 추가하여 반복 일정의 핵심 비즈니스 로직 검증

---

과제 셀프회고

• 처음에 과제를 파악하지 않고 시작해서, 어떤 걸 해야하는지 몰랐던 점이 컸던 것 같습니다.
• TDD라고 해서 무작정 테스트를 작성해야한다고 생각했는데, 먼저 프로젝트를 이해하고 하는게 낫다고 생각합니다.
• TDD, BDD의 중요성과 생산성에 대해서 꽤 많은 점을 배울 수 있었습니다.

기술적 성장

• 과제를 시작하기 전에, 여러 TDD에 대한 영상을 많이 학습했습니다.

• "feconf의 프론트엔드에서 TDD를 하는 방법과", "kakao에서 TDD를 통해 개발기간을 단축시킨 사례" 였습니다.

• Given-When-Then 구조의 장점은 사람이 이해하기 쉽고, AI도 이해하기 쉽다는 것이 큰 장점입니다.

• 이를 통해, 프로젝트의 명세서를 테스트코드로 명확하게 작성하고, 빠르게 테스트를 작성하여 생산성과 안정성을 확보할 수 있습니다.

코드 품질

• 실제로 테스트코드에 모두 Given-When-Then 구조로 가져가니, 테스트 코드의 가독성이 높아졌습니다.
• 기존에는 실행해서 성공하는 것에 만족했다면, 테스트 코드를 보더라도 스토리가 보여서 어떤 내용을 작성한 건지 알기 쉬워졌습니다.

// 31일 매월 반복 테스트 (PR 템플릿 필수 요구사항)
describe('generateRepeatDates - 31일 기준 매월 반복 처리', () => {
  test('31일이 없는 달은 제외된다', () => {
    // Given: 31일 기준 매월 반복 설정이 있는 이벤트
    // When: generateRepeatDates 함수로 반복 날짜를 계산할 때
    // Then: 31일이 없는 달(2월, 4월, 6월, 9월, 11월)은 제외되어야 한다
  });
});

// 윤년 처리 테스트 (PR 템플릿 필수 요구사항)
describe('generateRepeatDates - 윤년 2월 29일 매년 반복 처리', () => {
  test('평년에는 해당 날짜가 생성되지 않는다', () => {
    // Given: 윤년 2024년 2월 29일 기준 매년 반복 설정이 있는 이벤트
    // When: generateRepeatDates 함수로 향후 3년간 반복 날짜를 계산할 때
    // Then: 평년(2025, 2026, 2027)에는 해당 날짜가 생성되지 않아야 한다
  });
});

학습 효과 분석

• 계속 Given-When-Then구조를 가져가진 않겠지만, 프로젝트의 이해도가 부족하거나 개발 초기단계라면 적극적으로 도입해보고 싶습니다.
• 설계에 조금 더 시간을 많이 투자하면, 뒤에 코드를 개발하거나 수정할 때 굉장히 적은 비용이 발생하는 것을 알 수 있었습니다.
• 실제로 이번 과제는 TDD를 작성해서 그런지, 이전보다 리팩토링을 하는 과정이 매우 적었습니다.

리뷰 받고 싶은 내용

• Given-When-Then 구조로 TDD를 작성해보니 프로젝트 설계의 중요성이 더 커지는 것 같아요.
• 실제로 현업에서 사용해보려고 했는데, 기한이 촉박하다보니 UI 개발에 다시 치중하게 되었어요.
• 스토리북을 작성하는 것은 테스트의 단계중 어디에 해당하는 걸까요?
• 컴포넌트 개발 -> 스토리북 테스트 -> TDD를 통한 화면 퍼블리싱 -> 디자인 반영 -> ...
  • 위같은 개발 방법으로 시도해보면 좋을까요?!