k-sang-soo 님의 상세페이지[8팀 김상수] Chapter 3-1. 프론트엔드 테스트 코드 🧦

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 하는 시간을 줄일 수 있을 것 같은데 회사에서 그런 시간을 줄 수 없다면 어떻게 설득을 해야될까요??

과제 피드백

안녕하세요 상수님! 7주차 과제 잘 진행해주셨네요 ㅎㅎ 고생하셨습니다!

실무에서 단위, 통합 테스트까지 테스트 코드 짜는 경우가 많을까요? 그냥 제 생각에는 테스트 코드를 짠다고 하면 e2e 테스트가 시간 대비 가장 효율적일것 같긴한데 어떻게 생각하시나요??

말씀해주신 것 처럼 e2e 테스트만 있어도 대부분의 케이스는 커버 가능하다고 생각합니다! 다만 e2e의 경우 실행 시간이 무척 오래 걸리고, 테스트를 실행하는 컴퓨팅 비용도 단위 테스트보다 비싸요. 그래서 자주 실행하기가 부담스럽고, 그러다보면 대체로 마지막 단계에 검증하는 경우가 많답니다 ㅎㅎ 실패에 대한 피드백을 빠르게 받기가 어렵기 때문에 개선하기 까지의 과정이 조금 더 오래걸리죠. 대신 정확도는 높아요!

반대로 빠르게 문제를 찾아낼 수 있는 단계가 단위테스트이지만, 말 그대로 단위테스트이기 때문에 다양한 비즈니스의 결합에 대해 검증하기는 어려운거죠.

결론은 테스트의 목적과 효과 자체가 다르기 때문에 적절한 전략이 필요하다고 생각해요!

테스트 코드를 짜면 확실히 유지보수 할 때 QA 하는 시간을 줄일 수 있을 것 같은데 회사에서 그런 시간을 줄 수 없다면 어떻게 설득을 해야될까요??

테스트를 한방에 뽝 작성해놓고 "만들었어요!" 라고 해보는거죠 ㅋㅋ 이미 만들어놨고, 효과가 있다면 이에 대해서 "굳이?" 라고 이야기를 꺼낼 사람은 많이 없다고 생각해요. 물론 테스트 자체도 유지보수를 해야하기 때문에 이에 대한 부담이 있을 수는 있죠!

특히 테스트가 "설득보단 용서" 라는 키워드에 어울린다고 생각해요. 도입했을 때 안 좋을 게 딱히 없다보니..