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

[Jihoon-Yoon96]

과제 3

필수 스펙

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

기본 과제

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

기본과제 제출

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

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

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

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

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

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

심화 과제

심화 과제 제출

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

---

심화과제 진행 과정

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

일단, 대부분 회사 일을 놓을 수 없는 분들이 대부분이라 과제 진척률이 낮아서 우리 팀에선 회의가 그리 활발하진 않았던 것 같다. 그래도 팀 내부에서 스스로를 생각했을 때 가장 적극적이고 열심히하는 포지션이기 때문에 팀원들의 의견을 열심히 이끌어는 봤다.

팀원 모두가 '통합테스트'를 중심으로 보강해야 한다고 주장할 것 같았고, 예상이 적중했다. 나는 팀원들에게 생각거리를 던져보기 위해 일부러 나의 생각과는 다르게 "단위테스트"를 보강해야 된다는 입장에 섰다. 우선 내가 주장한 '단테파'의 의견은 아래와 같다.

• 이번 프로젝트(3주차 과제)는 "테스트에 익숙치 않은 사람들이 5일만에 마무리해야하기에, 시간 대비 효율을 고려했을 때 단위테스트 위주로 보강해야 한다.
• 단테에서 확인 못하는 사항들의 경우에만 e2e와 통테를 최소한으로 운용하는 것이 기간 내에 마무리 하기에 적합하다.
• 기능에 대한 검증이 완벽하다면 그것만으로도 신뢰할만한 결과로 봐도 무방하며, 추후에 통테 및 e2e테스트로 넘어가기에도 적합하다.

내 얘기를 듣자 조용하던 팀원들이 너도 나도 의견을 내주기 시작했다(이 부분에서 매우 뿌듯했음).

• 시간적 한계 때문에 단테 위주로 돌린다 해도 결국 '통테'에서만 확인할 수 있는 영역들에 대한 검증이 더 중요하기 때문에 (기능간 결합, UI변화 등) 유의미한 테스트 결과를 낼 수 있으려면 통테를 보강하는 것이 맞다.
• 드래그&드랍 같이 실제 화면에서 확인해야하는 경우만 e2e로 진행해야 하며, 우리는 1-2주차 과제를 통해 기능들에 대한 검증을 수없이 해왔기 때문에 더 이상의 단테는 무의미하다.
• 기본으로 제공된 테스트 케이스들을 보면 통합테스트 파트에서 누락된 케이스들이 많이 발견되고 있으니, 이 부분에 대한 보강을 우선시 하는 게 좋을 것 이다.

나도 원래 통합테스트를 (몰래) 고수하고 있었지만 "1-2주차 과제로 기능들에 대한 검증은 충분"하다는 두 번째 의견은 단테를 더 이상 주장하기 힘듦을 느끼게 했다.
그래서 7팀은 '이번 과제의 신규 기능 개발 건'에 대한 E2E 테스트(드래그앤드랍)와 통합테스트(클릭 시 이벤트폼) 보강하는 전략을 세웠다.

심화과제 결과물

• E2E : playwright/test/DND/drag-drop-workflow.spec.ts
• 통합 :
  src/tests/integration/MonthView.EventForm.integration.spec.tsx
  src/tests/integration/WeekView.EventForm.integration.spec.tsx

---

과제 셀프회고

일단 끝냈음에 스스로에게 너무 감사하다... AI에 지쳐 일-월을 그냥 허송세월 보내버린 탓에 화,수,목 의 시간밖에 없어 4일돈안 8시간밖에 못 잔 것 같지만.. 그래도 이렇게 결과물을 내고 피드백을 받게 되어 뿌듯하다.

1. 드래그 앤 드랍 개발

라이브러리 없이 개발했다. 1,2주차 과제 진행하면서 MUI 라이브러리(특히 셀렉트박스 ㅡㅡ!)부분 쿼링에 상당한 문제를 겪었기 때문에,
이와 같은 문제를 더 이상 겪고 싶지 않았다. 그리고, 어차피 UI만 제공해주지 사실 엔드포인트나 핸들러에 대한 기능 개발을 하는건 똑같다 생각했다.
1주밖에 안되긴 했지만 AI 없이 순수 개발을 해서 뇌가 즐거웠다.

2. 클릭 시 일정 수정 폼 채우기

일정 클릭시 인풋박스 하나하나 접근해서 값을 채울까 했지만, 생각해보니 handleEditEvent함수가 있어 자식 컴포넌트로 내려주었다.
이 부분에서 굳이 흠이라하면 props 드릴링..? 그래도 추가로 개발해야하는 기능들 쉽게 개발해네어 뿌듯했다.

11/8(토)에 추가 긴급 회고..

• 팀 코드리뷰를 진행하다보니 과제 명세들 중 일부를 '잘못'이해한게 있더군요..
• "셀 클릭 시 해당 날짜가 이벤트 입력 폼에 입력됨" 를 "셀에 있는 이벤트를 클릭 시 입력 폼에 이벤트 정보들이 기입됨" 으로 이해하고 진행함..
• 원래 의도하신 기능은 귀가해서 작업해보겠습니다 ㅠ..

3. 시각적 회귀 테스트 (storybook, chromatic)

들어만보고 써본적이 없어 난감했지만, 생각보다 쉬웠다. 공식 문서에서 args를 공통화하는 방법을 찾은 덕에, 스토리마다 코드 수를 좀 더 줄일 수 있었다.
UI 컴포넌트를 개별적으로/여러개를 엮어서 확인도 하고, UI 소스 수정에 대한 스냅샷을 기록하여(크로마틱) 의도한 변화가 맞는 지 체크하는 것도 재밌었다.

4. E2E 테스트 (playwright)

진짜... 젤 쉬울줄 알았던 놈이 제일 어려웠다 ㅠ vitest에 익숙해져있던 쿼링법에 뒷통수를 치는...
발제시간에 오프코치님이 "유지보수 측면에서 효율적인 쿼링 방법"에 대해 생각해보라 하셨는데, 공식문서를 찾아보니 POM 패턴(Page 객체 - https://playwright.dev/docs/pom)가 그에 해당하는 방법 같았다.
테스트 시 페이지와 상호작용하는 페이지 객체에 접근하게 하여 재사용성을 높이고 한 번의 수정으로 여러 테스트에 적용시키기 용이한 구조... 하지만 이것을 따라하려는 수많은 시도가 무색하게 해내지 못하였다 ㅠ.. (만약 나 혼자 이 방법을 도용했더라면 BP를 노려봐도 되지 않았을까? 하는 망상도 했음ㅎ,,)
비록 구현에는 실패했지만, 처음 써보는 사람이 이런게 있다는 걸 찾아낸 것도 용하다 생각한다.

기술적 성장

1. 테스트 과정 중 UI검증에 대한 필요성
   멘토링 시간때 과제를 다 하지도 못했음에도 다음 주차 발제 내용인 "CSR" 관련된 질문을 했는데, 뜻밖에도 이번 주차 학습에 중요한 요점을 얻어냈다.
   준일 코치님께서 "프론트엔드가 전문적으로 필요해진 시점은 스마트폰이 공급된 시점과 유사하다."라는 말씀과 함께 "다양한 화면에 대한 효율적인 개발을 위해" 지금의 수요가 완성됐을 것이라 하셨다.
   이 말을 듣기 전까진, 단위테스트로 기능을 검증하고 이를 통합한 시나리오를 통테에서 검증한다면 UI에 대한 검증을 많이 가져가도 될까?를 생각했다. 확실히, csr이든 ssr이든 프론트엔드도 개발 과정에서 데이터의 변화에 집중하며 화면 개발을 하는게 중요하다 생각했던 나에게 UI적인 검증에 필요성을 일깨워준 것 같다.

코드 품질

playwright 소스는 이런 저런 시도(환경 세팅, 쿼링 방법 학슴, POM패턴 도입 등)들을 하느라 놓친 부분이 많은 것 같다.
나름 헬퍼함수(e2eHelper.ts)를 구현하여 자주 쓰이는 함수들을 공통화 하는 데에 성공했지만, 테스트에 대한 setup 파트를 공통화 할 수 있지 않았을까 생각한다.

학습 효과 분석

과제 피드백

리뷰 받고 싶은 내용

• ./playwright/test/notification-workflow.spec.ts 중 '알림 시간에 도래하면 알림 문구 노출'
• 위에 적은 테스트 케이스 뿐 아니라, e2e테스트와 시각적 회귀 테스트를 진행하면서, 1,2주차 통합테스트에서 검증했던 내용들과 많이 겹침을 느꼈습니다.
  과제 명세가 해당 항목들에 대한 CRUD를 구현하는 것이니 테스트 내용이 겹침에도 작성은 하였지만, 과연 통테/단테에서 진행 및 검수된 내용을 또 다시 검사하는 게 과연 효율적일까? 가 궁금합니다.