[7팀 황준태] Chapter 1-3. 완성도있는 테스트 전략 수립하기

[jthw1005]

과제 3

필수 스펙

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

기본 과제

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

기본과제 제출

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

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

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

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

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

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

심화 과제

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

심화 과제 제출

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

본 프로젝트의 일정 관리 서비스에서는 화면이 많이 없고, 캘린더의 month 또는 day를 바탕으로 계산하는 로직이 주라고 판단하여 유틸함수에 대한 단위 테스트가 많이 필요하다고 생각했습니다.
한편, 현재 구현되어 있는 설계를 보면 비즈니스 로직이 탑다운 방식으로 내려져와 다양한 컴포넌트에서 쓰이고 있기 때문에 통합 테스트 또한 많이 필요하다고 생각했습니다.
마지막으로 E2E 테스트는 드래그 앤 드롭과 같이 단위/통합 테스트에서 검증하기 어려운 부분에만 국소적으로 써야겠다고 생각했습니다.
따라서, 단위 50%, 통합 40%, E2E 10% 정도의 전략을 구상했습니다. 단, 현재 프로젝트에서 단위 테스트는 이미 많이 있는 것 같아서 통합 테스트와 E2E 테스트를 중점적으로 추가하면 될 것 같다고 생각했습니다.

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

팀원들 대부분이 비슷하게 생각하신거 같아 저희팀의 전략을 정하는데 그리 오랜 시간이 걸리진 않았습니다. 팀원 분들 대부분이 통합 테스트가 단위 테스트 보다는 시간이 걸리는 것은 사실이지만서도 그 효과는 명확한 부분임으로 통합 테스트를 중점적으로 가져가고 DND와 같은 기능에 한해 E2E 테스트를 가져가는 것으로 결론이 났습니다.

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

additionalSpec.e2e.spec.ts

👉 E2E 테스트: DND 관련 테스트 코드 3개 & 캘린더 내 날짜 클릭으로 입력 폼 내 날짜를 채워주는 기능 1개

additional.spec.ts

👉 통합 테스트: 주간/월간 뷰 변경에 따른 올바른 일정 렌더링 & 캘린더 내 날짜 클릭 관련 로직 등 6개

---

과제 셀프회고

E2E 및 시각적 회귀 테스트를 작성해보는 것은 처음이라서, 발제 이후 화요일까지는 Playwright 강의나 인프런 테스트 코드 강의를 주로 찾아봤습니다. 강의를 들을 때는 '아 이렇게 쓰는구나, 이해 다 된다, 신기하다' 했는데, 막상 테스트 코드를 작성할려고 보니 결국 다시 다 찾아보게됐습니다. 역시 강의를 듣기만 하는 것보다는 직접 키보드를 두들기면서 그때마다 찾아보는게 좋은 학습법인 것을 다시 한 번 깨달았습니다;

Playwright로 테스트를 진행하는 방식 조차 생소했습니다. 크로미움, 파이어폭스, 웹킷을 테스트하는 방식도 생소했고, 초반에는 테스트 돌리는게 익숙치 않아서 디버깅 모드로 돌릴 떄와 일반 모드로 돌릴 때, cli 창에서 실행할 때 각기 다른 결과가 나오기도 했습니다. 과제를 할 시간은 없는데, 자꾸 다른 곳에서 막혀서 답답하기도 했습니다.

그래도 클로드와 클로드 코드를 최대한 활용해서 익숙해지고 어떻게 짤까 고민하는 과정에서 초반보다는 다소 익숙해져 어떻게 꾸역꾸역 과제는 전부 해낸 것 같습니다. 아직 깔끔한 쿼링 방식 또는 독립적인 mock 데이터 구축 등 보완해야 할 부분들이 많이 있어서 앞으로 해당 부분을 위주로 공부해 나가면 될 것 같습니다.

기술적 성장

이번주를 끝으로 한 챕터가 마무리되었으므로 전반적인 회고를 해보자면, 3주 동안 테스트 코드 개념에 대해 많이 배우고 성장한 것 같습니다. 항상 테스트 코드의 중요성만 듣고 테스트 코드를 작성해볼까해도 우선 순위에서 밀려 제대로 작성해 볼 기회가 없었는데, 이번 3주 동안 테스트 코드도 꽤 써보고 어떻게 작성해야할지 고민도 많이 해보고, TDD 사이클을 기반으로 한 에이전트도 활용해보면서 테스트 코드를 쓰는 것에 대해 자신감이 붙었습니다.

코드 품질

테스트 코드에 대한 품질만을 놓고 봤을 때는 코드 품질 측면에서 보완해야 할 점이 많다고 생각합니다. 이제서야 알게된 사실이지만, waitfor과 같은 api 들은 최대한 안 쓰는게 좋은데 이번 과제에서 불필요한 부분에 종종 사용했었고, 쿼링하는 방식이 익숙치 않아 꾸역꾸역 요소를 찾아내는 코드도 꽤 있습니다.
이러한 부분은 앞으로 많은 테스트 코드를 작성해보고 좋은 테스트 코드를 찾아보면서 보완해 나가야 할 것 같습니다.

Chromatic 라이브러리

과제 피드백

고민해야하는 부분들이 중간중간 적절히 있고 실제 코드를 구현하는 부분 또한 적절히 많이 있어서 배울 점이나 생각할 점이 많은 과제였습니다!

리뷰 받고 싶은 내용

1. 요소를 깔끔하고 유지보수에 용이하게 쿼링하는 방법, 여러 테스트 환경들에 대한 설정이나 CI/CD를 관리하는 방법, 독립적인 mock data를 운영하는 방법 등 채워야 하는 부족한 부분들이 많은데, 잘 학습하기 위해서는 좋은 테스트 코드를 찾아보고 많이 구현해보면 될까요?
2. 멘토링 시간에 언급해주신 Gamification이 저랑도 굉장히 잘 맞는거 같습니다! 혹시 평소에 Gamification을 어떻게 활용하셨는지 좀 더 얘기해주실 수 있을까요?