BangDori 님의 상세페이지[7팀 강병준] Chapter 3-2. 프론트엔드 테스트 코드

8주차 과제 체크포인트

기본 과제

필수

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

심화 과제

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

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

image

페어 4팀 테스트 전략 회의실

페어 4팀(4팀/7팀)은 각 팀원들이 테스트(단위/통합/E2E)에 대해 어떻게 생각하는지를 이야기를 나누고 어떤 식으로 테스트 피라미드를 설정하면 좋을지 의견을 나누었습니다. 또한 팀원들과 의견을 주고받는 과정에서 질문을 통해 어떤 테스트에 어떻게 비중을 두는 것이 좋을 지를 이야기를 나누며 테스트의 중요성과 필요성에 대해 느낄 수 있는 좋은 시간이었습니다.

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

이번 과제에서는 코드의 안정성을 단계별로 튼튼하게 쌓아 올리는 피라미드 테스트 전략을 채택했습니다. TDD로 과제를 진행해야 했기 때문에, 가장 작고 예측 가능한 순수 함수부터 검증하는 단위 테스트로 시작했습니다. 이 튼튼한 기반 위에서, 훅과 컴포넌트 등의 각 부품들이 서로 잘 연결되어 동작하는지 확인하는 통합 테스트를 진행했고, 마지막으로 실제 사용자와 같은 환경에서 전체 시나리오를 검증하는 E2E 테스트로 마무리하며 각 계층이 서로를 보완하도록 설계했습니다.

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

recurringEvents.spec.ts (단위 테스트)

반복 일정 기능의 핵심 로직을 검증하는 포괄적인 단위 테스트를 추가했습니다. 매일/매주/매월/매년 반복, 엣지 케이스 처리, 단일 인스턴스 수정/삭제 등 모든 주요 기능에 대한 테스트 커버리지를 확보하여 기능의 안정성을 보장합니다.

  • 반복 유형별 테스트: 매일/매주/매월/매년 반복 일정 생성 검증
  • 엣지 케이스 처리: 31일이 없는 달, 윤년 등 특수한 날짜 처리
  • 수정/삭제 테스트: 단일 인스턴스 수정 시 반복 패턴 분리, 삭제 시 다른 반복 일정 유지
  • UI 표시 검증: 반복 아이콘 표시 로직 및 시각적 구분

medium.integration.spec.tsx: (통합 테스트)

일정 관리 시스템에서 반복 일정 기능을 검증하는 테스트를 추가했습니다.

  • 매일 반복: 달력에 여러 날짜에 걸쳐 일정 표시
  • 단일 인스턴스 수정: 반복 일정 중 하나 수정 시 해당 날짜만 단일 일정으로 변경
  • 단일 인스턴스 삭제: 반복 일정 중 하나 삭제 시 해당 날짜만 사라짐
  • 원본 반복 일정 관리: 원본 수정 시 모든 미래 가상 일정 변경, 원본 삭제 시 모든 가상 일정 제거

calendar.cy.ts: (E2E 테스트)

실제 사용자의 관점에서 일정 관리 시스템의 전체 워크플로우를 검증하는 E2E 테스트를 추가했습니다. 브라우저 환경에서 실제 사용자 상호작용을 시뮬레이션하여 CRUD 기능, 반복 일정, 뷰 전환, 검색, 유효성 검사 등 모든 핵심 기능의 통합 동작을 검증합니다.

  1. 기본 CRUD (Create, Read, Update, Delete)
  • 생성: 사용자가 새 단일 일정을 성공적으로 생성하는 시나리오
  • 수정: 기존 일정을 성공적으로 수정하는 시나리오
  • 삭제: 기존 일정을 삭제하는 시나리오
  1. 반복 일정 기능
  • 매주 반복 생성: 주간 반복 일정 생성 및 캘린더 표시 검증
  • 가상 인스턴스 수정: 반복 일정 중 특정 날짜만 단일 일정으로 수정
  • 원본 삭제: 반복 일정의 원본을 삭제하여 모든 가상 인스턴스 제거
  1. 캘린더 뷰 및 검색
  • 뷰 전환: 월별/주간 뷰 전환 및 날짜 이동 기능
  • 키워드 검색: 일정 제목 기반 검색 및 결과 필터링
  1. 유효성 검사 및 예외 처리
  • 필수 필드 검증: 제목 없이 일정 생성 시도 시 에러 처리
  • 일정 충돌 처리: 겹치는 시간에 일정 생성 시 경고 다이얼로그 표시

과제 셀프회고

기술적 성장

4팀의 소희님과 페어 프로그래밍을 하면서 서로의 코드를 바라보는 시각 차이를 경험할 수 있었습니다. 저는 기능을 빠르게 구현하는 데 집중하는 편이었는데, 소희님은 코드의 가독성과 테스트 가능성을 고려하며 구조화하려는 모습이 인상적이었습니다. 그 과정에서 제가 놓친 부분들을 피드백받을 수 있었고, 반대로 제가 생각한 로직의 흐름을 설명하면서 제 의도를 명확히 표현하는 연습도 되었습니다.

테스트를 할 때 테스트 코드에 대한 의도를 파악하는 것이 굉장히 중요하다는 것을 배웠습니다. 기존에는 테스트의 정상 동작, 반례 그리고 경계값에 대해서만 알고 있었는데 이 외에도 많은 유형의 테스트가 존재한다는 점을 알게 되었습니다. 그리고 이런 테스트 유형에 대한 용어까지도..!!

Happy Path (정상 동작)

  • 기대하는 입력 -> 기대하는 출력
  • 의도한 시나리오가 잘 수행되는지 확인하는 테스트

Negative Case (반례)

  • 잘못된 입력, 잘못된 상태, 예외 상황에서 적절한 에러나 반환값이 나오는지 확인
  • ex) null, 빈 배열, 타입 불일치, 권한 없는 요청 등

Boundary Value (경계값)

  • 최소값, 최대값, 임계값 근처를 집중적으로 테스트
  • ex) 배열 길이 0, 1, N, N+1 / int 최소값·최대값

Exception / Error Handling (예외 상황/에러 핸들링)

  • 단순히 “반례”보다 더 세분화: 외부 API 실패, DB 연결 끊김, 네트워크 타임아웃, 파일 없음 등
  • 코드가 안전하게 실패하는지 확인하는 테스트

Performance / Stress (성능/부하 관련 테스트)

  • 단위 테스트라면 보통은 안 하지만, 경우에 따라서는 대량 데이터 입력이나 반복 실행에서 문제 없는지 확인
  • 대량의 입출력 데이터를 다루는 경우에 유용할 수 있는 테스트

State Transition (상태 전이 테스트)

  • 객체/시스템의 상태 변화가 올바른지 확인
  • ex) 로그인 → 세션 발급 → 로그아웃 → 세션 해제

Deterministic Control (비결정적 요소 테스트)

  • 랜덤, 현재 시간, 외부 환경 의존성을 Mock/Stubbing으로 통제해서 “의도된 동작”을 보장하는지 확인

Contract Test (호환성/계약 검증)

  • 함수 시그니처, API 응답 포맷, 인터페이스 규약이 변하지 않는지 보장
  • 특히 공통 모듈/라이브러리에서 중요

Regression Test (회귀 테스트)

  • 과거 버그가 재발하지 않도록, 발견된 버그에 대한 테스트 케이스 추가

코드 품질

  • AI로 대부분의 코드를 작성해서 엄청나게 만족스럽거나 아쉬운 코드가 잘 느껴지지 못했던 것 같습니다...!

학습 효과 분석

  • 팀원들과 피그잼에서 테스트에 대한 의견을 공유하고 서로 질문하는 과정에서 각 테스트가 어떤 역할을 잘 수행해야 하는지 그리고 왜 필요한지에 대해 명확히 기준을 정리할 수 있었습니다.

단위 테스트

  • 최소 단위의 모듈(함수, 공통 컴포넌트 등)을 검증하기 위한 테스트로서 개별 모듈이 정상적으로 동작하는지를 테스트하기 위한 것
  • 모듈을 신뢰할 수 있는가?

통합 테스트

  • 여러 개의 모듈(컴포넌트, 서비스, 훅 등)이 서로 상호작용하는 과정을 검증하기 위한 테스트. 단일 함수가 올바르게 동작하는지 보는 게 아니라, 이벤트 → 여러 모듈 호출 → 결과라는 흐름이 끊김 없이 잘 이어지는지를 확인하는 것
  • 모듈들이 서로 잘 맞물리는가?

E2E 테스트

  • 사용자 관점에서 서비스의 전체 흐름(워크플로우)을 끝까지 검증하는 테스트
  • 사용자가 실제로 이 제품을 써서 원하는 가치를 얻을 수 있는가?

리뷰 받고 싶은 내용

이번 주에는 서울로 이사를 한다고 과제를 진행하는데 있어 많은 시간을 할애하지 못했는데 소희님이 많이 도와주신 덕분에 과제를 할 수 있었습니다!

과제 피드백

수고했습니다. 이번 과제는 TDD 방법론을 실제로 경험해보면서 테스트 주도 개발의 Red-Green-Refactor 사이클을 체험하는데 목적이 있었습니다.

테스트 유형에 대한 정리가 정말 체계적입니다. Happy Path부터 시작해서 Regression Test까지, 각각의 목적을 명확히 이해하신 것 같아요. 특히 "모듈을 신뢰할 수 있는가?", "모듈들이 서로 잘 맞물리는가?", "사용자가 실제로 이 제품을 써서 원하는 가치를 얻을 수 있는가?"라는 질문으로 단위/통합/E2E 테스트를 구분한 것이 직관적이고 좋습니다.

소희님과의 페어 프로그래밍 경험도 값진 것 같네요. "저는 기능을 빠르게 구현하는 데 집중하는 편이었는데, 소희님은 코드의 가독성과 테스트 가능성을 고려하며 구조화하려는 모습"이라고 하신 부분에서, 서로 다른 관점이 어떻게 보완될 수 있는지 체험하신 것 같아요. 실무에서도 이런 상호보완적 관점이 정말 중요하거든요.

"AI로 대부분의 코드를 작성해서 엄청나게 만족스럽거나 아쉬운 코드가 잘 느껴지지 못했던 것 같습니다" 요새 고민이 참 많이 되는 부분입니다. 발제나 강의보다도 과제에 포커싱을 두는 것은 결국 직접적인 체험으로 배우는게 제일 좋다고는 생각했었는데, 확실히 AI가 나오면서 훨씬 더 접근성이 낮아지고 할 수 있는 것이 더 많아진 반면 AI를 통해 작성된 코드나 결과물에 대해서는 애착이나 성취면에서 확실히 경험이 달라진 것 같아요. AI를 도구로 활용하면서도 테스트 설계나 전략 수립 같은 핵심적인 사고 과정을 잘 경험해주신 것 같아요.

다음 과제도 화이팅입니다!