[데브로드] 5주차 주간회고

이번 주 배운 것들

- 테스트 작성 훈련
- TDD의 BDD 개념 정리
- Given-When-Then
- Unit Test
- Jest, DOM Testing Library, React Testing Library
- Mocking Fixture
- MSW
- Playweight

개인 공부
- 알고리즘 풀이(해쉬 key-value 5문제)
- React 18 버전 업데이트 내역 정리(현재 리엑트가 어떤 방향성을 가지고 가고 있는지에 대해 알기 위해 공부) -> 리엑트는 18버전에서 "동시성"에 포커싱하여 많은 기능들을 추가하였다.
   => 알게된 개념: Suspense, 자동 일괄 처리(Automatic Batching), Transitions, React Server Component 
         🚨 위 기능들을 사용하기 위해서 React 18 버전부터 바뀐 Root API를 적용해야 사용 가능하다.
- Redux(스터디) - (기본적인 개념에 대해 공부했다. React useContext, useReducer에 대한 개념을 알고 들어가니, 내용들이 재밌었다.)
- Jest Docs, DOM Testing Library Docs, React Testing Library Docs 정독 및 나만의 Docs 정리

이번 주는 시작부터 험난한 길의 시작이었다. 바로 TDD였다. 그 동안에 알고 있었던 TDD는 TDD가 아니었다는 걸 깨닫는 순간 나의 고통은 시작되었다. 처음에는 호기심과 재미로 가득차 시작을 하게 되었다. 이 이야기도 정말 웃길 수도 있지만, 나에게는 정말 해보고 싶었던 것이기도 했었기 때문이었다. 

강의를 들은 후 하나 하나 정리를 하며 개념을 잡아보았고, 머리속에 어느 정도 정리되어 강의 내용을 실제로 따라해본 후 반복으로 여러 번작성하면서 조금씩 익숙해지고 있었다. 데브노트를 마친 후 과제를 시작하게 되었는데 이번 주 과제는 TDD로 테스트 주도 개발로 시작하여 모든 과제를 마치는게 미션이었다. 하나씩 과제를 진행을 해보자 하는 생각에 테스트 파일을 먼저 생성 후 한참동안 멍 때렸던 나를 볼 수 있었다. 

그때 생각했던게 일단 내가 알고 있는 개념으로 TDD 연습을 해야겠다라는 접근을 시작으로 TDD의 Cycle(Red-Green-Refector)을 준수하여, 테스트 코드 작성 후 -> 실제 코드 작성 -> 리펙토링 사이클을 반복해서 작성을 해보았다. 시작 전 각 컴포넌트의 의도에 따라 어떻게 테스트 코드를 작성하면 좋을지를 고민한 후 주석으로 메모를 남긴 후 하나씩 Jest 및 React Testing Library API에 따라 작성을 해보았다. 작성을 하면서 어떤 Test API가 적절할지를 구글링 해보며 전체 코드의 50% 이상 완성을 한 상태였다. 이대로 쭉 꾸역꾸역 작성하여 완성 시킬 수도 있었지만 나는 이 시점에서 큰 결심을 했다.

"내가 지금 이 과제를 완성하기 위해가 아닌 미래의 나를 위해 잠시 과제를 멈추고 Jest, Testing Library에 대해 정확한 개념에 대해 알아보고 다시 진행해보자!"  

제일 먼저 찾아서 본 곳은 공식 문서였다. 공식 문서를 보니 너무 재밌는 내용들이 많았다. 시간 가는 줄 모르고 문서를 정리해보기 시작했다. 과제에서 테스트 코드 작성 시 Jest의 beforeEach에 대해 강의 때 배웠던 내용이 있었지만, 정확히 어떤 시점에 실행되는지에 대한 Jest 라이프사이클에 대해 알 수 있었다. 

예제를 정리해보면서 재미있었던 점은 outer의 beforeEach와 inner의 beforeAll, inner의 beforeEach 였다. beforeAll은 테스트 코드가 실행 전 딱 한번 실행하고, beforeEach는 각 테스트 함수가 실행될 때마다 실행된다. 반대로 after도 같은 개념이라고 보면되는데 전 -> 후로 바뀐다. 위에서 1이라고 표시한 부분 테스트가 실행될 때, outer의 beforeEach가 먼저 실행되고 inner의 beforeAll이 실행 될 것 같았지만, inner의 beforeAll이 먼저 실행되는 것을 보고 신기했었던 기억이 있다.

이후에도 여러가지 테스트들을 묶어주는 describe에서도 재밌는 부분들이 있었다. 동일한 테스트를 진행 시 테스트를 여러번 할 때 유용하게 사용할 수 있는 describe.each, 설명 블록을 하나만 실행하는 describe.only, 테스트를 건너뛰고 싶으면 describe.skip 등 활용할 수 있는 부분들이 있었다. 추가적으로 과제 진행 시 주석으로 내가 할일들을 정리했었는데 Jest에서 제공해 주는 test.todo를 사용하여 내가 미리 작성할 테스트를 정리하는 방법도 알게되었다.

어느정도의 Jest의 정리를 끝낸 후 나는 Testing Library로 넘어갔다. Testing Library에서 흥미로웠던 부분은 바로 'data-testid'였다. 과제 진행 중 테스트를 진행할 때 나도 의도치 않게 사용했었던 것이었다. 그래서 공식 Docs를 보니 내가 잘못 쓰고 있던 것을 알게되었다. 'data-testid'는 텍스트 콘텐츠와 레이블이 의미가 없거나 실용적이지 않은 요소에 대한 '탈출구'로 제공하는 것이었는데 나는 의도치 않게 제대로 알지 못하고 사용했던 것이었다. 'data-testid'를 사용한다고 가정하여 production 배포 시에는 요소를 어떻게 지울까도 찾아보고 babel을 통해 해결이 가능하다는 생각들을 한 내가 부끄러웠다. 

기존에 Jest로도 내가 원하는 요소를 API를 통해 Select 할 수 있었지만, Testing Library에서는 Jest 문법 쓰지말고 'screen'을 사용하여 모두 표현 가능하니 'screen'을 최대한 써라 라고 권장하였던 부분도 재밌는 부분이었다.  screen안에 멍청하게 console.log를 찍어서 확인하고 싶었던 내 자신이 부끄럽게 screen.debug도 제공하는 것도 확인하였다. 또한 아직 써보진 않았지만 브라우저에서 열 수 있는 URL을 로깅하고 반환하는 방법인 screen.logTestingPlaygroundURL()도 제공해준다. 이후 React Testing Library에서도 render를 효율적으로 사용할 수 있는 방법들에 대해서 정독한 후 숙지하여, React Testing Library에 대한 컨벤션과 궁금했던 것들을 찾던 중 React Testing Library를 개발한 Kent C. Dodds가 적은 글 중 React Testing Library는 이렇게 쓰세요 하는 가이드라인의 글을 보고 많은 것을 배울 수 있었다.

https://kentcdodds.com/blog/common-mistakes-with-react-testing-library

나는 배운 지식들을 토대로 모든 테스트 코드를 리펙토링 작업을 시작했다. 너무 신세계를 느꼈다. 속도가 전에 비해 5배 정도는 향상된 느낌이었다. "아! 이 부분은 이렇게 처리하는게 조금 더 권장하는 방법이었고, 아! 이거는 어느 버전 이전에는 이렇게 많이 썼지만 최신 버전에는 생략해서 쓸 수있어 등"을 깨달으며, 전체적인 테스트 코드를 Kent C. Dodds가 권장하는 방식으로 공통화 작업을 진행하였다. 2~3일을 삽질해서 걸렸던 나의 시간들이 딱 1시간안에 모두 뚝딱 리펙토링하였다. 매우 뿌듯했던 순간이었다. 

회고가 너무 길어지는 것 같아 글을 마무리 하려고 한다. 다음 주는 이번 주에 미뤄졌던 과제를 마무리 한 후 다시 진도에 맞춰 나아가는 것을 목표로 궁금했던 리엑트 내부를 한번 까보는 시간을 가지려고 한다. 다음 주도 파이팅!