[2팀 이정민] Chapter 1-3. 완성도있는 테스트 전략 수립하기

[LEE-jm96]

과제 3

필수 스펙

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

기본 과제

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

기본과제 제출

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

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

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

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

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

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

심화 과제

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

심화 과제 제출

• 내가 생각한 최적의 테스트 전략은 무엇인지, 그리고 그 이유를 작성해주세요.
• 팀원들이 합의한 최적의 테스트 전략은 무엇인지, 그리고 그 이유를 작성해주세요.
• 그 전략에 맞춰 추가한 테스트는 무엇인지 나타내주세요.

1. 제가 생각한 최적의 테스트 전략은 테스트 트로피 모델입니다.
   App.tsx 기반 구조를 살펴봤을 때 일정 생성/수정, 일정 검색, 반복 일정, MUI UI 구성 등을 통합테스트로 진행하고 hooks·utils 등을 단위 테스트로 진행해야 한다고 생각합니다. 그 이유는 App.tsx의 구조가 기능 단위로 명확히 분리되어 있고, 일정 생성/수정, 검색, 반복 일정 등은 MUI 기반 UI와 상태 로직이 함께 얽힌 구조이기 때문에 단위 테스트로는 실제 동작을 보장하기 어렵다고 생각합니다. 캘린더 드래그앤드롭, 반복 일정 저장 등 핵심 유저 플로우는 e2e로 검증하고 이외에는 통합 테스트에 비중을 두어야 한다고 생각합니다.

2. 팀원들이 합의한 최적의 테스트 전략은 아래 노션 링크에 정리하였습니다.
   https://www.notion.so/teamsparta/Chapter-1-3-29f2dc3ef5148050bd21ef5d1a47c400

3. 제가 추가한 테스트는 아래 파일입니다.
   (1). useEventForm(단위 테스트): easy.useEventForm.spec.ts
   (2). 날짜 클릭으로 일정 생성 기능 개발(통합 테스트): dataClickEventCreation.spec.ts
   (3). 날짜 클릭으로 일정 생성 기능 개발(e2e 테스트): dataClickEventCreation.e2e.spec.ts
   (4). dnd(e2e 테스트): dragAndDropEventManagement.e2e.spec.ts

---

과제 셀프회고

기술적 성장

3주차 과제를 진행하면서 E2E 테스트를 처음 작성해보았고, 크로마틱(Chromatic) 을 활용한 시각적 회귀 테스트 또한 처음 경험했습니다.
처음에는 크로마틱과 플레이라이트(Playwright)를 모두 사용해본 적이 없어 다소 당황했지만, 팀원들과 함께 각 라이브러리의 기본 개념과 사용법을 학습하면서 점차 방향을 잡아갈 수 있었습니다.

E2E 테스트는 Playwright를 활용해 구현했으며, CRX 툴을 사용해 브라우저 상에서 캘린더 기능을 직접 수행하면서
자동으로 테스트 코드가 생성되도록 하여 작성 효율을 높일 수 있었습니다.

시각적 회귀 테스트는 Chromatic을 이용해 스토리북의 각 컴포넌트를 빌드하고,
변경된 화면의 스냅샷을 시각적으로 비교·검증하는 과정을 통해 UI 안정성을 확보할 수 있었습니다.

구현 과정에서 실제 데이터베이스를 변경하고 싶지 않아 E2E 전용 데이터베이스를 별도로 생성하였습니다.
E2E 테스트를 진행할 때는 각 테스트가 종료될 때마다 기존 E2E 초기 데이터로 복원되도록 구성하여, 실제 E2E 데이터에 영향을 주지 않고 안전하게 테스트를 수행할 수 있었다는 점이 만족스러웠습니다.

코드 품질

이번 테스트코드를 작성하면서 만족스러웠던 부분은 위에서 언급한 e2e.json을 따로 분리한 것입니다.
테스트 중에는 데이터 생성, 수정, 삭제가 자주 일어나는데, 이를 실서버(DB)에서 수행하면 기존 데이터가 훼손되거나 왜곡될 위험이 있습니다.

또한 setup 함수를 통해 각 테스트 종료 후 E2E용 데이터베이스를 초기 상태로 복원하도록 구성한 점도 만족스러웠습니다.
이 덕분에 어떤 테스트를 실행하더라도 항상 동일한 조건에서 시작할 수 있었고, 그 결과 테스트 간 데이터 일관성을 안정적으로 유지할 수 있었습니다.

학습 효과 분석

이번 과제를 통해 드래그 앤 드롭 기능을 직접 구현해보았습니다.
저는 HTML Drag & Drop API를 사용했고, 팀원 중 한 명은 Dnd Kit 라이브러리를 활용했습니다.
Dnd Kit을 사용한 팀원에게서 “드래그 아웃 시 선택한 셀이 잠시 원래 위치로 되돌아가는 버그”가 발생했다고 들어, 두 방식의 차이점을 공부해보았습니다.

HTML 기본 DnD의 경우, 드래그가 시작되면 draggedEventId 상태만 빠르게 초기화되어 즉각적인 반응이 가능했고, 드래그 중인 요소가 반투명 → 불투명으로 전환되는 시각적 변화를 즉시 인식할 수 있었습니다. 그래서 실제 데이터 위치 변경이 다소 지연되더라도 거의 눈에 띄지 않았습니다.

반면, Dnd Kit은 드래그된 요소를 라이브러리 내부에서 직접 관리하기 때문에, 시각적 이동뿐만 아니라 실제 데이터 상태와의 동기화가 필요했습니다. 이 과정에서 상태 업데이트가 지연되면 요소가 순간적으로 원래 위치로 되돌아가는 것처럼 보이는 현상이 발생했고, 이를 해결하기 위해서는 낙관적 업데이트(Optimistic Update) 를 적용하여 실제 데이터가 반영되기 전에도 화면에서는 먼저 변경된 상태를 보여주는 접근이 필요했습니다.

과제 피드백

E2E 테스트를 진행하면서, E2E 테스트와 통합 테스트의 차이에 대해 곰곰이 생각해보게 되었습니다.
특히 DnD(드래그 앤 드롭) 기능의 테스트 코드를 작성하면서, 이 기능을 E2E로 작성할지, 통합 테스트로 작성할지 팀원들과 함께 여러 차례 고민했습니다.

처음에는 사용자 관점에서 보았을 때 DnD는 “일정을 수정하는 실제 행위”에 해당하므로 E2E 테스트로 검증하는 것이 적절하다고 생각했습니다.
하지만 점점 개발자 관점에서도 “DnD 로직이 올바르게 작동하는가”를 확인하는 통합 테스트의 필요성을 느꼈습니다.

오프 코치님께서 말씀하신 것처럼, 이런 경우에는 “어느 쪽이 맞을까?”를 고민하기보다 두 가지 관점 모두에서 테스트를 작성해보는 것이 가장 확실한 방법이라는 결론을 내렸습니다.

이번 경험을 통해 테스트의 목적과 범위를 상황에 따라 유연하게 적용하는 것이 중요하다는 점을 배웠습니다.

리뷰 받고 싶은 내용

E2E 테스트 환경 (e2e)을 다음과 같이 구성하여 E2E 테스트를 진행하였습니다.
├── e2e.json (테스트용 데이터)
└── e2e.backup.json (백업 및 복원용)

각 테스트를 시작하기 전에 e2e.json 파일을 항상 초기 상태로 리셋하여 테스트 데이터를 보호했고,
이 덕분에 데이터 손실 없이 상태 변화를 추적하기도 훨씬 수월했습니다.

저는 이번 과제가 첫 e2e 테스트 경험이었는데요,
실제 현업에서도 이렇게 테스트를 직렬로 처리하면서, 각 테스트 시작 전에 데이터를 초기화한 뒤 실행하는 방식을 사용하는 경우가 있는지 궁금합니다!

페어 프로그래밍 느낀점

개발은 언제든 혼자서도 할 수 있지만, 팀원들과의 회의는 언제나 가능한 일이 아니기에 그만큼 소중하게 느껴졌습니다.
테스트 전략을 함께 논의하며 서로의 의견을 나누는 과정에서 다양한 시각을 접할 수 있었고, 생각의 폭도 한층 넓어졌습니다.

제가 생각하기에 우리 팀은 마치 ‘어벤져스 팀’ 같습니다.
모두 실력이 뛰어나지만, 그보다 더 인상적인 것은 높은 학구열과 집중력, 그리고 깊은 사고입니다. 단순히 “이게 되네?”에서 멈추지 않고,
“왜 되는지”, “어떤 원리로 그렇게 되는지”를 끝까지 이해하려는 태도를 가지고 있습니다.
그리고 놀랍게도, 팀원 전원이 그런 성향을 지닌 것 같습니다.

덕분에 나는 팀원들이 먼저 길을 열어주면 그 길을 비교적 쉽게 따라가고 있습니다.
회의 시간에 그들의 토론을 듣기만 해도 “와, 이렇게까지 깊게 생각하고 이야기할 수 있구나” 하는 감탄이 절로 나옵니다.
비록 내가 말을 많이 하진 않지만, 그들의 대화를 듣는 것만으로도 내가 성장하고 있다는 확신을 얻고 있습니다.

https://main--6909aeb4d891fee17b11a533.chromatic.com/ (크로마틱 참조)