2021/10/04 : 테스트코드는 테스트대상과 가깝게 유지한다.

지금, 이 리팩터링을 하기 전에는 모든 테스트 코드가 src/__test__ 폴더 내에 통합, 단위 테스트의 단위로 저장되어 있었다.

 

사람도 물리적인 거리가 멀어지면, 마음이 식듯이

개인적인 느낌으로는 테스트코드도 테스트대상과 멀어지니까, 테스트 대상(여기서는 컴포넌트)이 리팩터링 또는 기능 및 인터페이스가 변경되었을 경우,

 

"테스트 코드도 수정해야지"라는 마음이 쉽게 들지 않았다.

심지어 다른 컴포넌트와 병합되거나 삭제된 컴포넌트들도 테스트를 돌려보기 전까지 살아있던 경우도 있었다.

 

그래서, 모든 테스트코드를 테스트 대상과 가까운 거리로 옮겼다.

이제 테스트코드들은 해당 테스트 대상(컴포넌트)와 한몸이 되었다.

폴더가 옮겨져도 함께 변경사항이 있을때도 함께 움직이고, 어떤 테스트 코드를 확인하고 싶을때 바로 옆에 포함되어 있는 테스트코드를 확인 하면된다.

 

사소한 리팩터링이었지만, 심리적으로 테스트 코드를 작성하는데 많은 보탬이 된것 같다.

https://github.com/woowacourse-teams/2021-darass/commit/f618cb1d26149c2faef6d081902effeeb51845aa

 

 

또한, 상단 컴포넌트가 하단 컴포넌트를 렌더링할때, 하단 컴포넌트 내의 훅이 호출되는 경우에는, 하단 컴포넌트의 훅까지 모킹해줘야하는가?

이 문제에 대해서는 모든 컴포넌트에 필요한 함수들을 커스텀훅으로 한번더 추출함으로써, 상단 컴포넌트가 하단 컴포넌트를 렌더링할때

하단 컴포넌트에서 사용하는 커스텀훅을 1번만 mocking하도록 설계를 했다.

 

예를들어, CommentInput이라는 컴포넌트내에서 사용하는 모든 함수는 useCommentInput이라는 커스텀훅이 반환한다.

그리고 CommentList라는 컴포넌트를 테스트할때에는 useCommentInput이 반환하는 함수및 값들을 모킹하여 CommentInput 자체의 렌더링에 아무 문제가 없게한다.

 

확실히 이렇게하니까, 테스트가 용이해지긴했다.

하지만, 모든 컴포넌트에 전용 커스텀훅이 존재해야했고, 함수명이 변경되거나 제거 및 수정이 필요할때,

커스텀 훅 파일과 컴포넌트간의 잦은 이동이 문제가 되었고, 모든 인자를 구조분해할당하니까 중복된 인자들이 눈에 거슬린다는 단점이 있었다.

이 부분은 잘하면 깨끗하게 해결할 수 있을 것 같은데.. 고민된다.

https://github.com/woowacourse-teams/2021-darass/commit/9d7ea85194c996c29f5814bc9f1675ce39799979