[7팀 이현지] Chapter 1-3. 완성도있는 테스트 전략 수립하기

[Leehyunji0715]

과제 3

필수 스펙

• 드래그 앤 드롭(D&D) 기능 개발
  • 캘린더의 일정을 마우스로 끌어 다른 날짜나 시간으로 옮기는 기능을 구현합니다.
• 날짜 클릭으로 일정 생성 기능 개발
  • 캘린더의 비어있는 날짜 셀을 클릭하면, 해당 날짜가 자동으로 폼에 채워지도록 하세요.

기본 과제

필수 스펙 개발과 E2E, 시각적 회귀 테스트를 모두 작성해주세요.

기본과제 제출

• 아래 작성된 E2E 테스트 작성은 필수입니다. 추가로 작성하고 싶다면 작성해주세요.
• 여기서 말하는 전반은 Create, Read, Update, Delete 모두에 해당합니다.

1. 기본 일정 관리 워크플로우 전반을 검증하세요.
2. 반복 일정 관리 워크플로우 전반을 검증하세요.
3. 일정 겹침 처리 방식에 대해 검증하세요.
4. 알림 시스템 관련 노출 조건에 대해 검증하세요.
5. 검색 및 필터링 전반에 대해 검증하세요.

• 아래 시각적 회귀 테스트는 필수 입니다. 추가로 작성하고 싶다면 작성해주세요.

1. 타입에 따른 캘린더 뷰 렌더링
2. 일정 상태별 시각적 표현
3. 다이얼로그 및 모달
4. 폼 컨트롤 상태
5. 각 셀 텍스트 길이에 따른 처리

♨️
이 과정에서 컴포넌트 리팩토링이 필요할 수 있습니다!
여유가 있다면 컴포넌트를 아름답게 분리하는 고민을 해주시면 좋지만,
당장은 적절한 스토리를 작성하는데 더 집중해주세요.
적절한 추상화, 응집도를 높이고 결합도를 낮추는
우아한 설계는 이후 주차때 좀 더 집중해봐요.

- 물론, AI를 활용해도 좋습니다.
- 기존에 작성한 테스트는 깨지지 않도록 해주세요.
  - 이 과정에서 테스트가 분리될 수도 작성법이 수정될 수도 있습니다.
  - 정말 불필요한 케이스가 아니면, 테스트 케이스를 삭제하는건 최소화 해주세요.
  - 추가로 필요한 테스트가 생길 수 있지만, 작성은 자유롭게 선택해서 진행해주세요.

심화 과제

테스트 전략 작성해보기의 내용을 참고해서 지금까지 작성했던 프로젝트에 대해 테스트 전략을 구상해보세요.

심화 과제 제출

• 내가 생각한 최적의 테스트 전략은 무엇인지, 그리고 그 이유를 작성해주세요.

통합테스트를 보완하는 것. 컴포넌트를 리팩토링하다가, 잘못 리팩토링해서 기존과 다르게 동작하는게 몇가지가 있었다.
캘린더와 캘린더 Navigator를 분리했는데, Navigator를 이동시켜도 캘린더 날짜가 바뀌지 않았다.
근데 CI/CD는 통과하길래, 통합 테스트가 필요한 부분들이 있다고 인지하게 되었다. 또한, 단위에는 에러, 경계값 위주로 하고 통합 테스트를 해서 올바른 입력값에 대한 검증을 하면 되지 않을까 생각했습니다.

• 팀원들이 합의한 최적의 테스트 전략은 무엇인지, 그리고 그 이유를 작성해주세요.

통합테스트. 기존 프로젝트 구조를 보면 이미 단위테스트에 대한 검증은 충분히 이뤄졌다고 생각함. (= 이미 피라미드 형태로 레포가 작성된 형태라고 생각)

• 그 전략에 맞춰 추가한 테스트는 무엇인지 나타내주세요.
  통합테스트를 하자! 라고 논의를 했는데, 정확히 어떤 테스트케이스를 할지까지는 합의? 결정은 못했습니다,, 아래 내용들은 테스트전략 논의할 때 추가 테스트가 필요할 것 같은 것들 중 언급되었던 테스트케이스들입니다!

1. [통합] Calendar Navigator를 눌렀을때, 캘린더가 Month 가 잘 바뀌는지.
2. [통합] Calendar Navigator의 Next 버튼을 누르면 이벤트 리스트에 10월 이벤트는 안 보이고, 11월 이벤트가 보인다.
3. [통합] Month/Week 따라 캘린더 날짜가 잘 바뀌는지. (Week 검증)
   • 참고로 Week일 때는, Month는 같은 달 날짜만 나오지만, Week는 다른 Month여도, 그 주차의 모든 일(day)들이 나옴
4. [통합] 테이블 셀을 클릭하면 '날짜' 입력란에 해당 날짜가 잘 입력되는지.
5. [E2E] 이벤트 드래그앤 드롭 10/20 -> 10/21 로 옮기기 작업

---

과제 셀프회고

2025-11-03 (월)

• Playwright 세팅을 하고 test를 돌리니 fail이 나길래 보니까, vitest의 테스트 대상 영역에 playwright의 tests/ 파일도 같이 포함되어있었다. vite.config.ts 에 테스트 설정의 exclude로 해당 영역 추가, node_modules도 테스트가 되길래 해당 부분도 exclude로 추가했다.
• 맨 처음에는 과제를 듣고 무작정 Playwright부터 작성하려 했다. 그러나 지난주 2주차 과제때, 준일코치님이 피드백으로 AI한테도 문제해결 전략을 물어볼때도 있다하셔서 한번 Gemini에게 어떤 순서로 과제를 풀어나가야하고, 왜 그 순서로 해야하는지 물어봤다. 그랬더니 체계적으로 단계와 이유를 말해주는데 납득이 가버렸다! Playwright 세팅만 해두고, 리팩토링 작업부터 들어갔다. (과제를 다 하고나니, 리팩토링부터 진행한것은 신의 한수였던거 같습니다!! 테스트에 안 다뤄진 케이스 찾기 + Storybook 작성할때 요긴하게 써먹었어요)
• AI 답변
  1단계: 초기 환경 설정 및 기반 다지기 🛠️ - 테스트 환경 구축 및 컴포넌트 정리로 후속 작업 효율 극대화.
  2단계: 핵심 기능 개발 및 시각적 회귀 테스트 병행 🎨 - 신규 기능 구현 및 UI/UX 의 시각적 안정성 조기 확보.
  3단계: E2E 테스트 작성: 기본 워크플로우 검증 (CRUD) ✅ - 캘린더 시스템의 가장 기본적인 기능 안정성 확보.
  4단계: E2E 테스트 작성: 고급 기능 검증 ⚙️
  5단계: 최종 검토 및 제출 준비 📝

2025-11-04 (화)

• 이번 과제는 브랜치를 만들어서 진행했다. 회사에서는 main 브랜치에다가 바로 코드를 커밋하는 방식으로 했던터라 거기에 습관이 되어서 지난 과제들도 똑같이 했었다. 그러니까 CI/CD 관리도 잘 되는 이점이 있었다. 특히나 리팩토링을 했는데, test에서 CI/CD 가 Fail해서 merge가 안되길래 봤더니, Repeat 폼의 렌더링 조건을 빼먹고 작성했었다. 확실히 테스트가 왜 중요한지, 브랜치로 관리하는게 더 체계적이고, 안전하다는 것을 알았다. Refactoring이라 해도 실수가 날 수 있기 때문이다.
• 리팩토링을 잘못했는데, CI/CD가 통과가 되어 커밋이 되었다. ⇒ 여기서 누락된 테스트를 찾았다. 뒷걸음치다가 쥐잡은 느낌?

2025-11-05 (수)

• 리팩토링, D&D 기능 완성! (라이브러리 없이 기본 기능으로 간단히 만들었다. 이게 맞나?)

2025-11-06 (목)

• E2E 시작. Playwright를 세팅하고 테스트를 작성하는데, 어쩔 때는 테스트가 통과하고 어쩔 때는 실패했다. 화요일 오프코치님 Q&A 시간때 질문으로 나왔던 Race Condition 이슈였다. => playwright.config.ts 수정 => parallel: false, 그리고 workers: 1 로 세팅하니 순차적으로 테스트가 실행되었다.
• E2E 세팅. playwright.config.ts의 webServer를 세팅했다. E2E때는 e2e.json을 참조하게 하기 위해 아래처럼 웹서버 세팅을 했다.

/* Run your local dev server before starting the tests*/
webServer: [
    {
      command: 'TEST_ENV=e2e pnpm run dev',
      url: 'http://localhost:5173/',
      reuseExistingServer: !process.env.CI,
      timeout: 10*

1000,
    },
  ],

기술적 성장

• 브랜치 관리의 중요성: 1주차, 2주차때는 무작정 main 브랜치에다가 코드 커밋했더니 CI/CD 통과를 못했었다. 몇몇분들이 브랜치 단위로 관리하는것을 보고, 브랜치를 생성해서 main에다가 merge 하는 방식으로 변경했다. 그랬더니 리팩토링을 잘못하거나, 테스트를 잘못했을 때, PULL REQUEST 단에서 오류를 다 캐치하게 되었다. 브랜치 단위로 관리하는 것의 중요성과 CI/CD 세팅의 중요성을 몸소 경험했다! 브랜치 Squash도 해보고,, Rebase도 해보고... Merge도 해보고.. 다양하게 시도해봐서 좋았다.
• 스토리북 + 크로마틱: 스토리북과 Chromatic 모두 이번에 처음 써봤다. 스토리북을 하면서 리액트 컴포넌트 단위로 잘 쪼개는게 정말 중요하다 느꼈고, 크로마틱또한 CI/CD에 쓰일 수 있다는 것을 처음 알았다.
• Playwright: Playwright는 개념만 알고 있었다. 실제로 제대로 써본거는 이번이 처음이었다. 분명 시나리오는 맞는데 Fail이 나오는것이 있었는데, 아무래도 비동기다보니 중간중간 해당 컴포넌트가 존재하는지 체크해야하는 것을 알게 되었다!

코드 품질

• Drag& Drop 할 때, 기존 Event를 삭제하고 해당 데이트 날짜에 Event를 추가하는 방식으로 우선 진행했다. (시간부족 ISSUE, 체력 ISSUE) api를 2번 호출하기도 하고, 토스트가 '삭제' -> '생성' 2번떠서 조금 맘에 안들었다. 지금보니 Event 수정 기능을 써도 됐을것 같다.
• 나름 고민해서 리액트 컴포넌트를 리팩토링하긴 했는데, 이게 맞는지 모르겠다. Event 추가/수정하는 입력폼을 EventBasicForm, RepeatInputForm? 이런식으로 기본정보와 반복정보를 받는 폼을 분리하기도 하고 했는데, 잘 한건지 잘 모르겠따. 훅은 분리할 생각도 못했다. useEventForm이 특히나 엄청 길었는데, 코드를 보니 딱히 건드릴게 없어보였다,,,ㅠㅠ 그나마 멘토링때 react hook form 소개해주셔서 그거를 참고하라 하신게 좋았다!

학습 효과 분석

• 이제는 테스트가 예전만큼 무섭지 않아여~ 병아리에서 테린이로 진화.

과제 피드백

• 다양한 기술을 접할 수 있어서 좋았습니다 (그 덕에 새벽잠을 많이 잤긴 했어요,,ㅎㅎ)

기타

• 10월 1일 Week뷰로 변경했을때, holidays가 나오지 않는 버그가 있는거 같습니다!! (개천절 안나와요!!)

리뷰 받고 싶은 내용

[Leehyunji0715]

Chromatic 링크
https://www.chromatic.com/build?appId=690c6362ae7c4fb4ce49f70d&number=6