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

[chen4023]

과제 3

필수 스펙

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

기본 과제

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

기본과제 제출

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

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

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

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

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

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

심화 과제

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

심화 과제 제출

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

①. E2E

• 사용자의 핵심 플로우를 기준으로 최소한으로 가져가는 방향.
• 이번 과제에서는 DnD는 E2E로 브라우저 상에서 동작하는 이벤트인 드래그엔 드롭이 실제 동작했을 때 날짜 변경이 올바르게 적용되었는지 테스트 검증이 필요할 듯
• 테스트 범위가 넓어지는 경우 다수의 개발자가 소통이나 비용적인 측면에서 좋지 않을 것 같음
• 테스트가 깨졌을 떄 원인을 찾기 어렵기 때문에, 관련된 단위, 통합 테스트를 촘촘하게 가져가는 방향으로 진행하면 좋을 것 같음

②. 통합 테스트

• API 연동이나 폼 흐름과 같이 여러 컴포넌트가 동시에 연관되어있는 경우에는 통합 테스트로 검증을 진행
• 통합테스트를 진행하면서 발생되는 버그를 파악해서 단위테스트 설계로 적용해나가는 방식으로 테스트 설계를 해보면 어떨지

③. 단위 테스트

• 단위 테스트는 실제 유저 플로우와 같은 핵심 비지니스 로직에 사용되는 훅이나 유틸 기준으로 검증 진행

• 구현에만 연관되어있는 기능은 불필요

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

1. 통합 테스트의 비중을 가장 높게 설계하자 -> 가성비가 가장 좋음 (단위 & E2E 커버 가능)
2. 엣지 케이스도 대부분 통합으로 관리하자 (e2e로 커버하기에는 선행 작업이 진행되어야 하는 케이스가 많음)

• 이번 과제는 작은 서비스라서 E2E , 통합 비중을 다르게 해도 큰 차이가 나지 않을 것 같음

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

1. 드래그 앤 드롭(D&D) 기능 개발
   브라우저의 이벤트를 기반으로 동작하기 때문에 e2e테스트를 통해 시나리오를 설정하여 검증했습니다.

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

---

과제 셀프회고

사실 항해에서 처음 테스트코드를 접하게 됐는데, 마지막 과제를 하면서 짧은 기간에 테스트에 대한 이해도 측면에서 많이 성장한 것 같다고 느꼈습니다. 추가적으로 D&D와 날짜 클릭 시, 폼에 날짜를 불어오는 기능을 구현하면서도 기존 코드에 대한 버그를 찾아 나가며 캘린더 서비스에 대한 이해 또한 높아졌다고 생각합니다.

기술적 성장

초반에 e2e테스트를 작성하고 CI를 돌렸을 때, 로컬에서 순차적으로 실행하면 잘 동작하던 테스트가 계속 실패하는 상황이 발생하였습니다.

단일 워커 + 테스트별 데이터 초기화 전략을 사용하여 하나의 e2e.json 파일에서 모든 테스트 데이터를 관리하되, /api/reset 엔드포인트를 통해 각 테스트 실행 전 데이터를 초기화하는 방식을 선택했습니다. 모든 테스트는 단일 워커에서 순차적으로 실행되며, beforeEach 훅을 통해 테스트 간 격리될 수 있도록 적용했습니다.

병렬을 사용하여 다중워커를 사용하는 방안도 고려해보았으나, 불필요한 파일이 생기게 된다고 판단하여 단일 워커로 진행하기는 했는데 규모가 커진다면 시간적인 비용을 줄이기 위해서라도 병렬로 테스트를 진행하는 것이 좋을 것 같습니다.

코드 품질

학습 효과 분석

과제 피드백

리뷰 받고 싶은 내용

1. 아키텍처 선택
   테스트 실행 시에 순차적인 테스트가 필요없는 경우, 무조건 병렬로 테스트를 돌리는게 좋을까요?
   혹은 병렬 실행으로 전환해야 하는 기준점이 있을까요?

2. 데이터 리셋 전략
   질문: /api/reset 엔드포인트를 만들어 테스트 진행 전 데이터를 초기화 시키는 방법을 사용하고 있는데 더 좋은 방법이 있을까요?

3. 타이밍 이슈 (알림 설정 기능)
   토스트나 alret과 같은 UI는 타이밍에 따라서 테스트가 실패하는 케이스가 있는 것 같은데, 방지할 수 있는 좋은 방안이 잇을까요?
   대부분 실패하면 waitForTimeout 메서드를 사용해서 해결했는데.. 별로 좋지 않은 방법인 것 같습니다.
   1분후 알림 예정인 경우, 테스트 내에서 실제로 1분이라는 시간을 기다렸다 테스트를 검증해야 하는지 궁금합니다. 만약 그 방안이 아니라면 테스트 케이스 내에서 시간을 조작하는 방법이 있을 것 같은데 실제 로컬에서는 잘 통과하지만 CI에서 돌아갈 때에는 시간 이슈로 통과하지 못한 케이스들이 있었는데 이부분은 조금 더 학습해 볼 예정입니다.

4. E2E와 통합 테스트의 경계

• e2e와 통합 테스트에서 겹치는 기능이 많다고 생각이 들었는데, 그 경계를 어디까지 두는 것이 적절한지 궁금합니다.
• 실서버 데이터 검증 vs 목업 데이터 기반 검증의 차이가 가장 큰 차이점이라고 생각이 드는데, 고려해서 경계를 구분하면 좋은 요소가 있을까요?

[ckdwns9121]

채은님! 테스트코드 3주차 동안 정말 고생 많으셨어요 😊

짧은 기간이었는데도 테스트 전략을 스스로 고민하고, E2E–통합–단위 테스트 간의 역할을 명확하게 구분해가며 적용한 과정이 채은님의 성장을 보는것 같아 재밌네여 ㅎㅎ

D&D 같은 까다로운 기능도 잘 풀어내셨고, CI에서의 이슈도 직접 해결해보신 게 큰 성장이라고 느껴집니다!

테스트 주차가 익숙하지 않으셨을텐데 끝까지 과제 잘 마무리해서 뿌듯합니다!!

다음 과제도 화이티잉👍‼️