8주차 과제 체크포인트
기본 과제
필수
- 반복 유형 선택
- 일정 생성 또는 수정 시 반복 유형을 선택할 수 있다.
- 반복 유형은 다음과 같다: 매일, 매주, 매월, 매년
- 31일에 매월을 선택한다면 -> 매월 마지막이 아닌, 31일에만 생성하세요.
- 윤년 29일에 매년을 선택한다면 -> 29일에만 생성하세요!
- 반복 일정 표시
- 캘린더 뷰에서 반복 일정을 시각적으로 구분하여 표시한다.
- 아이콘을 넣든 태그를 넣든 자유롭게 해보세요!
- 캘린더 뷰에서 반복 일정을 시각적으로 구분하여 표시한다.
- 반복 종료
- 반복 종료 조건을 지정할 수 있다.
- 옵션: 특정 날짜까지, 특정 횟수만큼, 또는 종료 없음 (예제 특성상, 2025-06-30까지)
- 반복 일정 단일 수정
- 반복일정을 수정하면 단일 일정으로 변경됩니다.
- 반복일정 아이콘도 사라집니다.
- 반복 일정 단일 삭제
- 반복일정을 삭제하면 해당 일정만 삭제합니다.
선택
- 반복 간격 설정
- 각 반복 유형에 대해 간격을 설정할 수 있다.
- 예: 2일마다, 3주마다, 2개월마다 등
- 예외 날짜 처리:
- 반복 일정 중 특정 날짜를 제외할 수 있다.
- 반복 일정 중 특정 날짜의 일정을 수정할 수 있다.
- 요일 지정 (주간 반복의 경우):
- 주간 반복 시 특정 요일을 선택할 수 있다.
- 월간 반복 옵션:
- 매월 특정 날짜에 반복되도록 설정할 수 있다.
- 매월 특정 순서의 요일에 반복되도록 설정할 수 있다.
- 반복 일정 전체 수정 및 삭제
- 반복 일정의 모든 일정을 수정할 수 있다.
- 반복 일정의 모든 일정을 삭제할 수 있다.
심화 과제
- 이 앱에 적합한 테스트 전략을 만들었나요?
각 팀원들의 테스트 전략은?
기능 회귀 테스트
합의된 테스트 전략과 그 이유는 무엇인가요?
"회귀테스트 중심의 안정성 보장 전략"
회귀 테스트는 새로운 기능 추가나 리팩터링이 기존 기능을 깨뜨리지 않았는지 보장하는 것이 핵심 목적입니다. 단순히 "전체 테스트"가 아니라 기존 기능 유지에 초점을 맞춘 안전망 역할을 합니다.
핵심 전략
-
회귀테스트 중심 접근
- 새로운 기능 추가 시 기존 기능이 깨지지 않았음을 보장
- 기능 간 상호작용 검증에 집중
- 통합적인 관점에서의 기능 검증
-
기존 기능 유지 보장
- 스키마 변경과 필드 추가에 대한 대응
- 새로운 필드나 로직 추가 시 기존 로직의 안정성 보장
- 연관 기능들의 정상 동작 검증
-
실제 사용자 시나리오 중심 테스트
- 이전 기능 재테스트가 아닌 기능 간 상호작용 검증
- 실제 사용자 플로우를 시뮬레이션하는 realistic한 테스트 구현
선택 이유
문제 상황
신규 기능 개발 진행 과정에서 기존 기능과 테스트 코드의 안정성을 보완하기 위해 회귀 테스트 도입을 검토하게 되었습니다. 그러나 팀원들 간 회귀 테스트에 대한 이해도가 상이하여 명확한 개념 정립이 필요한 상황이었습니다.
특히 회귀 테스트의 필요성에 대한 근본적인 의문이 제기되었습니다. 한 팀원이 "회귀 테스트가 새로운 기능을 붙일 때 안정성을 주는 것과 전체 테스트를 하는 것과 차이가 무엇인지", "회귀 테스트는 꼭 신규 기능 붙일 때만 의미 있는 건가요?"라는 질문을 던지면서 팀 차원의 논의가 시작되었습니다.
또한 회귀 테스트의 유형 선택에 대한 고민도 있었습니다. 시각적 회귀 테스트(Storybook의 크로마틱을 활용한 UI 기준 테스트)를 진행할 것인지, 아니면 기능 회귀 테스트(유닛테스트와 함께 사용하는 방식)를 진행할 것인지에 대한 결정이 필요했습니다. UI 픽셀 기반 회귀 테스트 전략의 필요성에 대해서는 팀 내에서 크게 필요하다는 의견이 없어, 기능 회귀 테스트 중심으로 논의를 진행하기로 했습니다.
주요 논의 과정
1단계: 회귀 테스트의 본질적 의미 탐구 앞서 제기된 질문에 대한 답변으로, 회귀 테스트는 새 기능이 아니라 기존 기능이 깨지지 않았는지 확인하는 것에 목적이 있다는 점이 강조되었습니다. 기능을 추가할 때 흔히 발생하는 문제는 이미 수정한 기능이 롤백되거나 다른 부분에 사이드이펙트를 주는 것인데, 이를 방지하는 것이 회귀 테스트의 핵심 역할이라고 정의했습니다.
"기능 A, B를 개발한 후 다시 테스트하는 것이 회귀 테스트인가?"라는 근본적인 질문부터 시작하여, 단순한 기능 재테스트와 회귀 테스트의 차이점을 명확히 구분하고자 했습니다.
이러한 논의 과정에서 회귀 테스트와 전체 테스트 간의 명확한 차이점을 정리했습니다:
| 구분 | 회귀테스트 (Regression Test) | 전체테스트 (Full Test Suite) |
|---|---|---|
| 목적 | 기존 기능이 여전히 잘 작동하는지 확인 | 애플리케이션의 모든 기능을 검증 |
| 실행 시점 | 코드 변경 후 | 정기적 또는 릴리스 전 |
| 테스트 범위 | 변경 영향을 받을 수 있는 기존 기능들 | 모든 기능 (신규 + 기존) |
| 실행 시간 | ⚡ 빠름 (일부 테스트만) | ⏱️ 오래 걸림 (모든 테스트) |
| 주요 관심사 | 기존 기능의 안정성 | 애플리케이션의 완전성 |
이러한 비교 분석을 통해 회귀 테스트가 단순히 "전체 테스트"가 아니라 안정성을 보장하는 안전망 역할을 한다는 점을 명확히 했습니다.
2단계: 구체적 목적과 적용 예시 도출 스키마 변경이나 새로운 필드 추가 시에도 기존 기능이 그대로 유지되는지 확인하는 것이 회귀 테스트의 주요 목적이라고 정의했습니다. 구체적인 테스트 시나리오를 통해 개념을 명확히 했습니다:
// 예시
describe('기존 반복 계산 로직이 excludeDates 추가 후에도 동일하게 동작한다');
describe('weekday 기능 추가 이후에도 기본 주간/월간/연간 로직은 동일하게 동작한다');
3단계: 팀 차원의 핵심 가치 합의 논의를 통해 도출된 회귀 테스트의 핵심 가치는 다음과 같습니다:
- 기존 기능의 유지 보장: 새로운 기능 추가 시 기존 기능이 정상 동작하는지 확인
- 연관 기능 검증: 여러 기능이 동작할 때 기존 동작 중 연관된 기능들의 정상 동작 확인
- 안전망 역할: 새 기능 추가 시 사이드이펙트 방지 및 소프트웨어 전체 안정성 개선
최종 수립 전략
회귀 테스트 유형 결정 시각적 회귀 테스트보다는 기능 회귀 테스트에 집중하기로 결정했습니다. 이는 현재 프로젝트의 신규 기능 개발 특성상 기능적 안정성이 더 중요하다고 판단했기 때문입니다.
회귀 테스트 작성 방향 단순한 기능 재테스트가 아닌 기능 간 상호작용 검증에 중점을 두기로 했습니다. 새로운 필드나 로직 추가 시 기존 로직의 안정성을 보장하고, 통합적인 관점에서 기능을 검증하는 것을 목표로 설정했습니다.
실무적 고려사항 "단일 일정 생성 기능 검증"과 같이 이미 존재하는 테스트 코드와의 중복 문제도 함께 검토하여, 효율적인 테스트 코드 작성 방안을 모색했습니다.
추가로 작성된 테스트 코드는 어떤 것들이 있나요?
파일 위치 : src/__tests__/회귀테스트.spec.tsx 여진석 PR
'회귀테스트: 반복일정과 기존 단일일정 충돌 검사'
-
반복일정 생성 시 기존 단일일정과 충돌하는 경우 경고가 표시된다
- 목적: 반복일정 기능 추가 후 기존 충돌 검사 로직이 정상 동작하는지 검증
- 검증: '일정 겹침 경고' 메시지와 구체적인 충돌 정보 표시 확인
-
반복일정의 특정 날짜가 기존 일정과 충돌하지 않는 경우 정상 생성된다
- 목적: 충돌하지 않는 반복일정이 정상적으로 생성되는지 검증
- 검증: 충돌 경고 없이 정상 생성 및 성공 메시지 확인
'회귀테스트: 검색 기능
-
반복일정이 검색 기능에 정상적으로 포함된다
- 목적: 반복일정과 단일일정이 검색 기능에서 올바르게 동작하는지 검증
- 검증: 검색 조건에 맞는 반복일정들이 모두 표시되는지 확인
-
반복일정이 있는 상태에서 검색 결과가 없으면 적절한 메시지를 표시한다
- 목적: 반복일정 환경에서 검색 결과가 없을 때의 UI 동작 검증
- 검증: "검색 결과가 없습니다." 메시지 표시 확인
'회귀테스트: 알림 기능
- 반복일정에 대한 알림이 각 일정마다 정상 동작한다
- 목적: 반복일정의 각 인스턴스별로 알림 기능이 정상 동작하는지 검증
- 검증: 개별 반복일정에 대한 정확한 알림 메시지 표시 확인
과제 셀프회고
기술적 성장
코드 품질
학습 효과 분석
과제 피드백
리뷰 받고 싶은 내용
과제 피드백
수고했습니다. 이번 과제는 TDD 방법론을 실제로 경험해보면서 테스트 주도 개발의 Red-Green-Refactor 사이클을 체험하는데 목적이 있었습니다.
팀에서 회귀 테스트 중심으로 접근한 것이 인상적이네요. "회귀 테스트가 전체 테스트와 무엇이 다른가?"부터 시작해서 목적, 실행 시점, 테스트 범위까지 정리한 점이 좋았어요. 특히 회귀 테스트를 "안정성을 보장하는 안전망"으로 정의한 것이 정확합니다.
사실 이번 과제의 취지는 TDD를 통해서 목표 - 설계(=테스트) - 구현 - 리팩토링 - 검증 이라는 개발 멘탈 모델을 한번 생각해보기를 바랬습니다. 그러면서 "테스트를 먼저 작성하고 그것을 통과하는 최소한의 코드를 구현"하는 과정에서 테스트 코드의 확장된 역할과 자연스럽게 더 나은 설계와 구조를 고민하게 되는 그 사고 과정을 경험해보는 거죠.
그렇지만 팀에서 회귀 테스트라는 관점으로 접근한 것 자체가 현업에서의 매우 실용적인 접근이죠. 테스트 코드의 역할과 이유 등에 대해서 이번 과제가 많은 것들을 겪어보는 계기가 되있기를 바래요.
다음 과제도 화이팅입니다!
OFF: 안녕하세요! 오프입니다. 제가 결과를 수정했는데요. 심화과제를 불합격 시킨 이유는 전에 공지에 공유드렸듯이 e2e, 시각적 회귀테스트가 없다는 맥락이였습니다. 아쉽지만 참고 부탁드립니다ㅠㅠ