진짜... 제발... 제가 작성 중 입니다.. 제발요,... 다시 찾아와주세요... 제발.......🥺🙏

감사합니다..최고

HARD

7주차 과제 체크포인트

기본과제

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

질문

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

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

심화 과제

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

과제 셀프회고

이번 테스트 챕터에 대해서 기대감이 있었습니다. 현업 프로젝트에서 테스트 코드를 따로 작성하지 않았기 때문에. 그리고 프론트엔드에서의 테스트 코드는 어떨지 정말 궁금했습니다.

결론부터 말씀드리면, 과제는 다 수행하지 못했습니다. 여러 이유가 있는데 이건 저의 WIL 회고 글 에 언급하겠습니다.

많은 시간을 할애하여 과제를 완성시키진 못했지만, 얕게라도 테스트 코드의 작성법, 테스트 코드는 어떤 구성으로 이뤄지는지, 그리고 테스트 코드가 ‘나’에게 미치는 영향도를 알 수 있는 시간이 됐습니다.

기술적 성장

테스트 프레임워크 및 도구 사용

• 테스트 러너 활용: Vitest의 고급 기능들(describe, it, beforeEach, afterEach)을 프로젝트에 적용
• React Testing Library: renderHook, act, screen, userEvent 등을 활용한 컴포넌트 테스트 작성 능력
• 테스트 유틸리티: assertDate 같은 커스텀 assertion 함수 작성 및 활용

코드 품질

학습 효과 분석

세상에 당연한건 없다.

이번 경험을 통해 내 머릿속에서는 당연한 것이 실제 코드에서는 그렇지 않을 수 있다는 점을 다시금 상기하게 됐습니다.

특히 테스트를 작성하면서 “이런 케이스가 정말 필요할까?”라는 스스로 질문을 던지게 되었고 그 과정에서 테스트의 필요성에 대해 곱씹어볼 수 있었습니다.

이렇게 생각해보니 테스트는 단순히 결과 확인을 위한 도구가 아닌 소프트웨어 디자인 과정의 일부라고 받아들일 수 있었습니다.

그리고 탄탄한 테스트가 뒷받침될 때 과감하게 리팩토링이 가능해지고 구현 코드의 완성도 또한 높아질 수 있음을 느꼈습니다.

즉, 테스트 코드는 “개발이 끝난 뒤에 덧붙이는 것”이 아니라, 기능을 설계하고 구현하는 과정 속에서 함께 쌓아가는 것이며, 개발자에게는 안정감과 자신감을 주는 것을 깨달았습니다.

과제 피드백

유닛 테스트에 대해서 단계별로 구성된 점과 테스트 케이스가 개인적으로 필요한지 아닌지 고민해보고 의견을 작성할 수 있는 환경을 만들어준 것이 좋았습니다.

리뷰 받고 싶은 내용

1. 테스트는 정적인 데이터를 활용하는게 좋다고 들었습니다. 하드코딩된 테스트 데이터를 별도 파일로 분리하는 것이 유지보수에 도움이 될지 궁금합니다.
2. beforeEach와 afterEach를 사용해서 테스트 상태를 초기화하는 것이 최선인지 궁금합니다. 또한 코치님이 사용하시는 방법이 있는지도 궁금합니다.