TDD 도입 도전!
회사 프로젝트로 여러 페이지에서 사용되는 카테고리를 만들고 있는데, 같은 카테고리로 사용할 수 없는 새로운 유형의 카테고리가 필요해서 TDD로 컴포넌트와 hook을 만들어 보려고 했다.
결과적으로는 실패했다.
아무래도 다른 유형이지만 비슷한 카테고리 컴포넌트를 이미 만든 상태에서 TDD로 새로운 컴포넌트를 만들려고 하다보니 “테스트” 보다 “코드”에 손이 먼저 가는 경우가 많았다.
테스트를 만들고 테스트를 통과하는 코드를 만드는게 아니라, 자연스럽게 코드를 만들고 테스트를 추가하는 상황이 발생하였다…
하지만 React Custom Hook을 만드는 좋은 예제를 보면서 TDD에 감을 익힐 수 있었다.
내가 실수한 부분은
- 훅, 컴포넌트, 함수의 요구사항을 파악하고 설계를 들어간게 아니라 코딩 부터 하려고 했었다.
- 심지어 테스트 코드를 위한 코딩도 아니고 실제 코드를 작성하고 있었다.
- TDD 원칙에서 벗어나서 계속해서 실제 코드를 만들고 이후에 테스트 코드를 작성하고 테스트를 실행하고 있었다.
- TDD 원칙에 따라 테스트가 실패하면
그 테스트를 성공할 수 있을 정도의 코드만 작성해야 하는데 그냥 생각나는데로 코드를 계속 작성하고 있었다.
개선해야할 점으로
- 요구사항을 명확하게 파악하고 설계에 들어가자.
- TDD를 사용해보기로 한 만큼, 테스트 코드를 먼저 작성하는 습관을 들이자
- 테스트 실패를 두려워하지 말자. 어차피 TDD는 실패에서 시작된다.
그래도 테스트를 작성하면서 테스트 없이 만들었던 컴포넌트와 훅의 설계 오류를 파악할 수 있었다. Context Menu에 전달할 때 단순히 클릭한 노드의 정보만 사용하고 있었는데, 내가 보낸 데이터는 Mouse Event에 관련된 거의 모든 정보를 보내고 있었다. 테스트를 만들지 않았다면 이렇게 불필요한 데이터가 필요한가? 라는 생각을 못했을것 같다…
jest-fetch-mock → MSW
컴포넌트, 훅에서 API를 요청하고 그에 대한 Response를 모킹하는 작업이 필요한데, 이전에는 jest-fetch-mock을 사용했었다. (사실 왜 썼는지 잘 기억이 안난다… 그냥 구글에 검색했을 때 나왔던 라이브러리로 기억)
하지만 이전에 MSW를 공부했던 기억이 나면서 MSW를 사용하는게 좋을 것 같아서 MSW로 변경하였다
내가 찾은 jest-fetch-mock의 단점으로는
hook을 테스트 할때, useEffect를 사용해서 초기에 API를 한번 호출하고 이후에 다른 함수를 사용해서 API를 호출해야 하는경우 모킹을 두번 해야 한다는 것이 불편했었고
Request Parameter, body 등을 따로 정의할 수 없다는게 불편했다.
하지만 MSW를 사용해서 특정 API 요청이 발생했을 때, body 또는 parameter에 따라 다른 응답을 보내도록 만들었다.
💡 jest-fetch-mock에 대해서 많이 알고 있지 않기 때문에 MSW와 같은 방법이 있음에도 내가 찾지 못한 것일 수 있다.TS-Challenge
타입스크립트를 제대로 배워보기 위해 타입 챌린지를 풀어보고 있다. Easy 난이도 5문제를 풀었는데
한 문제도 혼자서 풀지 못했다… 타입을 제대로 알고 있지 못하다는 생각이 들었고
타입스크립트를 이렇게 활용할 수 있구나라는 걸 배웠다. 그리고 문제에서 배운 내용을 회사 코드에 적용해보았다. 이전에는 불필요한 타입들을 많이 만들었구나 느꼈고, 타입 챌린지를 풀면 도움이 많이 될 것 같다.
매일 매일은 아니더라도 자주 풀어봐야지
