[8팀 김상수] Chapter 3-1. 프론트엔드 테스트 코드 🧦

[k-sang-soo]

HARD

7주차 과제 체크포인트

기본과제

• 총 11개의 파일, 115개의 단위 테스트를 무사히 작성하고 통과시킨다.

질문

Q. handlersUtils에 남긴 질문에 답변해주세요.

Q. 테스트를 독립적으로 구동시키기 위해 작성했던 설정들을 소개해주세요.

심화 과제

• App 컴포넌트 적절한 단위의 컴포넌트, 훅, 유틸 함수로 분리했는가?
• 해당 모듈들에 대한 적절한 테스트를 5개 이상 작성했는가?

과제 셀프회고

기술적 성장

vitest, RTL, MSW 같은 라이브러리들에 대한 사용법을 익히게 됐고, 그래도 vitest 나 RTL 같은 것들은 직접 사용해보지는 않았지만 눈으로는 많이 봐서 익숙한 느낌이였는데 MSW는 굉장히 낯설었는데 이번에 직접 테스트 유틸리티를 작성하면서 MSW의 역할이 어떤건지 이해하게 됐습니다.

코드 품질

Mock API Handler 팩토리 패턴

테스트 코드 작성 중 가장 고민이 깊었던 부분이 MSW 핸들러 구조였습니다. 처음에 작성되어있는 setupMockHandlerCreation, setupMockHandlerUpdating, setupMockHandlerDeletion 처럼 각 CRUD 작업별로 분리해서 작성하려고 했는데, 실제 테스트를 돌려보니 문제가 생겼습니다. 실제 API는 POST로 데이터를 생성하면 GET 요청 시 그 데이터가 포함되어 나와야되는데 테스트에서도 이런 '상태의 연속성'이 보장되어야 한다고 생각했고 각 핸들러가 독립적으로 동작하면 POST로 만든 데이터를 GET에서 확인할 수 없는 상황이 발생하기 떄문에 createMockEventHandler 라는 팩토리 함수로 통합했습니다.

클로저를 활용한 상태 공유로 testEvents 배열을 모든 CRUD 핸들러가 공유하면서, 실제 API처럼 데이터 변경이 즉시 반영됩니다. 그리고 사용할 때도 직관적이라고 생각합니다.

const mockHandler = createMockEventHandler();
server.use(mockHandler.get(), mockHandler.post());

각 메서드가 하나의 객체에 묶여있으니 관련성도 명확하고 테스트에서 사용할 API 핸들러 세트 라는 개념이 코드로 명확히 드러난다고 생각합니다.

학습 효과 분석

과제 피드백

다 좋은데 과제양이 너무 많습니다 살려주세요ㅠㅠ

리뷰 받고 싶은 내용

• 실무에서 단위,통합 테스트까지 테스트 코드 짜는 경우가 많을까요? 그냥 제 생각에는 테스트 코드를 짠다고 하면 e2e 테스트가 시간 대비 가장 효율적일것 같긴한데 어떻게 생각하시나요??
• 테스트 코드를 짜면 확실히 유지보수 할 때 QA 하는 시간을 줄일 수 있을 것 같은데 회사에서 그런 시간을 줄 수 없다면 어떻게 설득을 해야될까요??