HARD

7주차 과제 체크포인트

기본과제

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

질문

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

각 테스트에서 다루는 서버 상태(이벤트 데이터)가 따로 존재해야 안정적이게 동작할 수 있다고 생각합니다. 그래서 각 테스트 함수에서 이벤트를 따로 가질 수 있게 mock handler를 구성했습니다.

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

msw로 작성된 handler들이 독립된 데이터를 쓰도록 하고 각 테스트에서 재작성할 수 있게 하는 방식으로 처리하였습니다. 여기서 재작성하는 방식은 테스트코드에 직접 작성하는 방식도 있겠지만 이를 편리하게 재활용 할 수 있게 하기 위해 handlersUtils가 있는게 아닌가 했고 그래서 그런 용도로 handlersUtils를 사용하도록 했습니다.

심화 과제

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

과제 셀프회고

과제를 처음 시작할 때 테스트 코드 자체를 아예 처음 해보는 거라 내가 과제를 잘 수행 할 수 있을지 걱정이 많이 되었다. 그런데 막상 해보니까 생각보다 문법이 간단했고 아 뭐야! 괜히 쫄았네!! 하는 생각이 들었다. 나중에는 뭔가 요령이 생겨서 코드를 무슨 공장마냥 막 뽑아냈다... 그리고 뭔가 테스트 코드를 짜는 나만의 패턴(혹은 뭔가 나만의 전개 방식..?) 같은게 생긴 것 같은데... 근데 이거 좋은걸까..? 테스트 코드를 빨리 짜서 빨리빨리 뽑아낼 수 있게 되었다는 건 좋은 것 같긴 한데 뭔가 내가 친숙해진 패턴으로만 짜는 것 같다는 생각도 들어서 코드 자체가 다채롭지는 못한 것 같다.

근데 약간

"오~ 테스트 코드 언젠가는 해봐야지 ㅎㅎ" "테스트 코드 좋지!" "TDD 해보고 싶다!"

이렇게 말로만 해오던걸 항해하면서 반강제로 공부하고 해버리니까 밀린 숙제 끝낸 느낌이고... 일단은 앞으로 개발하면서 "테스트 코드를 도입해 볼까?" 라는 생각이 쉽게 들 것 같아서 좋다. 심리적 진입장벽이 많이 낮아졌다. 확실히 이렇게 한번 직접 부딪혀서 박살 내니까 용기가 생긴다. 앞으로 지레 쫄아서 미루지 말자는 생각도 들었다. 생각이 났을 때 진작 좀 해봤으면 더 좋았지 않았겠냐 싶어서 반성이 된다.

기술적 성장

이번에 RTL(React-Resting-Library)을 처음 사용해봐서 그 문법을 새로 학습했고, mock handler랑 handlersUtils 세팅을 하면서 msw도 처음 써봤다. 내가 짠 테스트 코드를 기반으로 리팩토링을 해본 것은 좋은 경험이었다. 나중에는 테스트 코드가 없이 리팩토링을 할 때 불편함을 느낄 수도 있을 것 같았다. 과제를 진행하면서 뭔가 나의 기준점이나 눈이 끌어올려 진 것 같다고 느꼈다.

코드 품질

뭔가 테스트 코드를 작성하면서 최대한 공정한...? 코드를 작성하려고 노력했다. 막 어떻게든 테스트를 통과시키기 위해 기상천외한 방식으로 테스트를 작성하는 것은 최대한 지양하고자 하였고 그 점이 대체로 마음에 든다.

학습 효과 분석

테스트 코드를 짜면서 테스트 코드나 케이스를 어떤 기준으로 / 어떻게 설정하는 것이 좋을지에 대한 고민을 했었다. 사실 테스트 케이스를 삭제하는 것 자체가 이로울 지에 대해 고민을 했었던 것 같다.

이건 그냥 단순해보이는데 / 혹은 단순 내장함수 테스트 로직 느낌이 드는데 이 케이스는 빼야하나? 이 테스트 케이스가 의미가 있나? 빼야하나? 그런 생각을 하면서 테스트들을 채워나갔고 지금까지 혼자서 든 생각은 사실 "함수 하나에 검증하는 로직이 꼼꼼하고 많을 수록 좋지 않겠냐" 였다. 어떻게보면 다다익선 식 결말인데 아직 테스트 케이스가 많을 경우에 무슨 단점이 있을지 잘 모르겠다.

가령

/**
 * 주어진 년도와 월의 일수를 반환합니다.
 */
export function getDaysInMonth(year: number, month: number): number {
  return new Date(year, month, 0).getDate();
}

이렇게 단순한 함수에도 테스트가 필요한가? 라는 주제로 고민했었는데 사실 지금 저 함수의 내부 로직은 뭔가 "정답" 에 가깝고 자주 바뀔 것 같지도 않지만 그래서 아예 바뀌지 않을 것이냐 하면 아닐 수도 있을 것 같고 내부 로직을 함수로 래핑하지 않고 그대로 쓰는거면 테스트가 필요 없을텐데 지금 저기는 getDaysInMonth 함수로 래핑을 한 상태다. 저 안의 로직을 어느날 누군가가 dayjs 라이브러리 라던가 를 사용해서 변경할 수 있는 가능성도 있다고 생각한다. 그래서 단순해 보이는 함수라도 저렇게 따로 선언해서 만들어 놨으면 테스트를 많이 만들어서 달아놓는 것이 좋지 않겠나 하고 생각했고 그래서 테스트들을 그대로 달아놓았다. 그래서 그렇게 생각하면 뭔가.. 테스트 자체에서 검증하고자 하는 내용이 타당하다면 많고 꼼꼼할 수록 좋은거 아닌가 하는 생각이 든다.

과제 피드백

과제 즐거웠어요! 저는 테스트 코드를 처음 접하는 사람이었는데 HARD를 수행하는 게 어렵긴 했지만 많이 성장 한 것 같고 처음 해보더라도 어느정도 애쓰면 수행할 수 있는 난이도 였던 것 같아요.

리뷰 받고 싶은 내용

테스트 코드는 다다익선인가요! 저는 사실 아직은 테스트 코드가 많을 경우 생길 단점을 모르겠어요. 납득이 되는 테스트 케이스라면 많은 것이 무조건 좋은거 아닌가 생각이 들어요.

• 테스트 코드가 많을 경우 생길 수 있는 단점이 있나요?
• 테스트 코드가 "지나치게" 많다 는 걸 판단할 수 있는 기준이나 안좋은 케이스 같은게 있을까요?