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

[im-binary]

과제 3

필수 스펙

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

기본 과제

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

기본과제 제출

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

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

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

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

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

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

심화 과제

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

심화 과제 제출

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

내가 생각한 최적의 테스트 전략

1. 통합 테스트 중심 (Integration Tests - 70%)

실제 사용자 시나리오를 테스트하여 여러 컴포넌트가 함께 작동하는 방식을 검증한다. 
Unit 테스트보다 많은 버그를 발견할 수 있으며, E2E보다 빠르고 안정적으로 테스트를 진행할 수 있다.

2. 단위 테스트는 선택적으로 (Unit Tests - 20%)

복잡한 로직을 가진 순수 함수나 커스텀 훅 정도만 검증해도 충분하다고 생각한다.

이유:
단순한 컴포넌트는 통합 테스트에서 자연스럽게 검증됨
구현 세부사항을 테스트하면 리팩토링 시 불필요하게 테스트가 깨짐
과도한 단위 테스트는 유지보수 비용만 증가시킴

4. E2E 테스트는 핵심 플로우만 (E2E Tests - 10%)

핵심 비즈니스 플로우(e.g. 회원가입, 결제, 일정 전체 CRUD)만 작성해도 충분하다고 생각한다.


이유:
느린 실행 속도: 브라우저 구동, 네트워크 요청 등으로 인해 E2E 테스트 1개만 돌아가는 시간만해도 아주 많은 유닛 테스트가 돌아가는 속도와 맞먹는다.

불안정성: 실제 유저 환경에서 동작하다보니 서버 부하, 네트워크 지연, 타이밍 이슈 등으로 간헐적 실패 발생

높은 유지보수 비용: UI 변경 시 셀렉터 수정 필요, 디버깅 어려움

CI/CD 병목: 빌드 파이프라인 시간 증가

팀원들이 합의한 최적의 테스트 전략과 이유

➡️ 이야기나눈 피그잼 링크

- 통합 테스트의 비중을 많이 두기
- 예외 케이스는 통합으로 진행시키기
  - 예외까지 E2E로 하기에는 빡셀듯
  - 선행 작업이 진행되어야 하는 케이스가 너무 많음
  - 관리하기 힘듬
- 커버리지 < 진짜 필요한 것만 (정상적인 케이스)
- 과제는 작은 서비스라서 E2E , 통합 비중을 다르게 해도 큰 차이가 나지 않을 것 같음

그 전략에 맞춰 추가한 테스트는 무엇인지 나타내주세요.

이번에 추가된 기능들에 대해 테스트를 어떻게 추가할까 고민해보았습니다.

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

테스트 전략

드래그 앤 드롭(D&D)의 경우, 실제 마우스 이벤트 시뮬레이션은 단위 테스트 수준에서 구현이 어렵기 때문에 E2E 테스트를 통해 정상 시나리오가 기대대로 동작하는지 검증했습니다.

➡️ 관련 커밋 링크

드래그 이후 발생할 수 있는 예외 상황(엣지 케이스)은 이미 기존 테스트에서 커버되고 있다고 판단하여, D&D 관련 통합 테스트는 별도로 작성하지 않았습니다.

날짜 클릭으로 일정 생성 기능은 기존 기능과의 연동을 고려해 통합 테스트를 추가했고, 전체 플로우가 정상적으로 작동하는지 검증했습니다.

➡️ 관련 커밋 링크

---

과제 셀프회고

기술적 성장

이번 과제를 통해 playwright 기반의 E2E 테스트를 설계하고 구축하는 경험을 했습니다. 단순히 테스트 도구를 사용하는 것을 넘어 실제로 운영중인 프로젝트에 도입한다면 어떻게 안정적으로 운영할 수 있을까를 고민했던 과제였습니다.

처음에는 조금은 E2E 테스트에 부정적인 시각을 가지고 있었습니다. E2E 테스트를 돌려야만 마음의 안정을 얻는 플로우라면 기획이 잘못된 것이 아닌가? 생각했습니다. 이전까지는 E2E 테스트를 단순히 유닛 테스트로 검증하기 어려운 UI 컴포넌트 (Slider와 같이 drag로 검증해야 하기 때문에) 등을 위한 보조 수단 정도로 생각했습니다. 하지만 실제로 프로젝트에 적용하면서 조금은 필요성을 체감할 수 있었습니다.

E2E 테스트는 실제 앱의 흐름을 재현하기 때문에 테스트를 실행하면 데이터가 추가, 수정, 삭제 됩니다. 그런데 테스트가 한 곳의 데이터를 건드리기 때문에 의도하지 않는 데이터를 가지고 있거나 의도한 데이터가 이미 등록되어 일정 겹침 문제를 일으켰습니다. 이 문제를 해결하기 위해 처음에는 테스트 완료 후 데이터를 초기화하는 전용 API를 server.js에 추가했습니다. (30b8075)

그런데 조금 더 생각해보니 실제로 프론트엔드 개발자가 테스트 전용 API를 백엔드에 요청하고 그 API를 백엔드가 만들어준다는 게 말이 안 되겠구나 싶었습니다. 그래서 실제 프로젝트에 도입할 때에 선택할 수 없는 방법이라고 생각했습니다.

그래서 데이터 초기화를 서버가 아닌 클라이언트 설정파일 e2e.json으로 옮겼습니다. 테스트가 완료되면 해당 파일의 데이터를 비우는 식으로 구현했습니다. 그러나 테스트 파일이 여러 개일 때 모든 테스트가 같은 저장소를 공유하니 여전히 데이터 충돌이 발생했습니다.

이 문제를 해결하기 위해 찾아보다가 Playwright의 워커라는 것을 발견했습니다.

처음에는 워커를 1로 고정해서 순차 실행하도록 했는데 40개의 테스트가 모두 완료되는데 7분이 걸렸습니다. 보통 PR 올리고 배포되기 전에 테스트가 깨지는지 CI가 한 번 돌텐데 이렇게 되면 테스트 하나 때문에 배포 속도가 느려지게 될 것 같았습니다. 조금 더 찾아보니 워커의 고유 ID가 있어 이 고유 ID를 활용해 별도의 저장소를 바라보도록 e2e-{id}.json 분리했습니다. 이렇게 하니 테스트 간 간섭을 차단하면서 병렬 실행이 가능해졌고, 40개의 테스트 실행 시간이 7분에서 4분으로 단축되었습니다.

이번 과제를 통해 E2E 테스트를 작성해본 경험 뿐만 아니라 어떻게 하면 테스트 환경을 잘 구축할 수 있을 지 경험해보았고 테스트를 작성할 수 있는 개발자에서 테스트 가능한 환경까지 구축해볼 수 있는 개발자로 성장한 것 같습니다.

코드 품질

• 병렬 테스트 환경에서의 데이터 격리 구현: Playwright의 병렬 실행 기능(worker)을 최대한 활용하면서도 테스트 간 데이터 오염을 막는 방법을 구현한 점이 가장 만족스럽습니다. 각 worker가 e2e-{workerId}.json이라는 고유한 데이터 파일을 참조하도록 설계하여, 테스트의 독립성과 실행 속도(7분 → 4분)를 개선할 수 있었습니다.

• 너무 거대한 E2EHelpers 파일: 현재 E2EHelpers.ts 파일에 테스트에 필요한 대부분의 헬퍼 함수가 모여있습니다. 아직까지는 테스트 작성할 때 괜찮았는데, 테스트 케이스가 더 복잡해지고 많아진다면 단일 파일이 너무 비대해져 유지보수가 어려워질 수 있을 것 같습니다. 추후 authHelpers, eventHelpers 등 기능 단위로 모듈을 분리하는 리팩토링을 해볼 수 있을 것 같습니다.

학습 효과 분석

테스트를 작성하고 환경을 구성해보면서 단순히 테스트를 작성하는 것을 넘어, 어떻게 하면 팀원들이 스트레스 없이 테스트를 실행하고 디버깅할 수 있을지, 테스트 경험을 개선하는 방법에 대해 더 깊이 학습하고 싶다는 생각이 들었습니다.

과제 피드백

이미 어느정도 진행된 프로젝트에 새로운 기능을 추가할 때마다 늘 “기존 기능이 깨지면 어쩌지?” 라는 걱정이 뒤따랐습니다. 이번 과제도 기존에 있는 프로젝트에 새로운 기능을 추가한다는 점에서 비슷한 상황이라고 생각이 드는데 이미 단위 테스트, 통합 테스트가 작성이 되어 있어서 그런 걱정을 덜어낼 수 있었습니다.

새로운 기능을 구현하면서도 기존 테스트가 계속 통과하는지 확인하는 것만으로도 심리적 안정감을 얻을 수 있었고 기존 기능이 올바르게 동작한다는 확신이 있으니 일일이 수동으로 점검할 필요가 없었던 것 같습니다. 테스트가 단순 검증 도구를 넘어 새로운 개발을 더 빠르고 자신있게 진행할 수 있게 해준다는 것을 체감할 수 있었습니다.

리뷰 받고 싶은 내용

E2EHelpers.ts 클래스의 구조 개선 방안에 대해 조언해주실 수 있나요?

우선, 반복되는 테스트 로직을 클래스(E2EHelpers.ts)로 묶어 재사용하는 접근 방식 자체가 괜찮은지 궁금합니다. 페이지 객체 모델(Page Object Model)과 유사하게, 공통 액션을 추상화하여 테스트 코드의 가독성과 유지보수성을 높이려고 의도했습니다. 이러한 헬퍼 클래스 설계가 일반적인 E2E 테스트 패턴에 부합하는지, 혹은 더 나은 대안이 있는지 1차적으로 검토받고 싶습니다.

만약 이 접근 방식이 유효하다면, 현재 구조의 확장성에 대한 피드백을 받고 싶습니다. 지금은 괜찮지만, 앞으로 테스트 케이스가 늘어나면 이 단일 클래스가 너무 비대해질 것 같습니다. 기능(e.g., 인증, 이벤트 생성, 뷰 전환)에 따라 이 클래스를 어떻게 분리하고 모듈화하는 것이 장기적인 유지보수 관점에서 가장 효율적일지 리뷰받고 싶습니다.

[ckdwns9121]

이진님 테스트코드 주차 수고많으셨습니다!
worker별로 e2e-{id}.json을 분리해 테스트 간 충돌을 제거한 방법이 참신하네요 ㅎㅎ
POM에 대한 개인적인 생각은 저희 회사도 POM 패턴을 사용하는거 같은데 이게 UI가 변경되어도 테스트로직 자체를 변경하지 않아도 되니까 편한거같아요!
특히나 페이지 규모가 커지거나 많아지면 더 좋을거같습니다ㅎㅎ

이진님 요번주도 화이팅~