[항해 플러스 프론트엔드 3기] 8주차 WIL

Q1. 과제

  테스트 코드 2주차!! 1주차에 비하면 비교적 양도 적고 쉬운 편이었으나, 그것은 어디까지나 1주차가 지옥의 난이도였기 때문이었습니다...! 2주차 역시 매운맛 과제였답니다... ㅠ_ㅠ..

  2주차 기본 과제는 캘린더 앱이 주어지고 모든 테스트 코드가 존재하는 상태에서 반복 일정 기능을 추가하되 TDD로 개발하는 것이었습니다. 기본적으로 일정 생성은 가능했고 반복 일정 옵션을 주면 일정이 여러개 생성되어 화면에 출력되는 그런 기능을 개발하는 과제였습니다. 심화 과제는 전체 앱에 대해 e2e 테스트나 시각적 회귀 테스트를 도입할 지 판단해보고 그 근거를 서술 하는 것과 실제로 일부 기능에 대해 도입해보는 것이었습니다.

  과제를 보고 기본 과제 정도는 통과하겠다 싶었는데 막상 시작하고 나니 쿼링하는 방법, 테스트 코드를 디버깅하는 방법, msw를 활용한 목킹 방법 등등 새롭게 공부해야하는 내용들이 많아서 처음 TDD를 해보는 제 기준으로 시간이 정말 많이 부족했습니다.ㅠㅠ

Q2. 시도

  테스트 코드 디버깅과 관련하여 난항을 많이 겪었는데요. 특히 DOM 요소를 쿼링할 때, 거대한 app 코드에서 screen.getByRole로 쿼링을 하니 내가 getByRole을 잘 못 쓰고 있는 건지, 실제로 screen에 요소가 없는 것인지 알기가 어려웠습니다.

Q3. 문제점

   getByRole은 첫 번째 파라미터로 role을 받고 두 번째 파라미터로 여러 옵션을 받는데 이 role과 options가 정상적으로 들어간 것인지를 정확히 알 지 못해서 더 방황했던 것 같습니다.

Q4. 해결

  쿼링에 실패하면 테스트 화면에 선택 가능한 요소를 Role과 함께 보여주는데 screen에서 찾은 경우 너무 많은 리스트가 출력됩니다. 따라서 screen이 아닌 좀 더 좁혀서 찾으려는 영역을 선택하고 within(좁은 영역).getByRole()로 접근하면 좀 더 적은 요소를 보여주기 때문에 문제점을 찾기가 더 쉬워집니다.

  또 한 가지 방법으로 getByRole로 안잡히면 getByText나 getByTestId로 일단 존재하는 지부터 체크하는 것입니다. 이렇게 하면 getByRole의 사용이 문제인지 테스트 코드 또는 실제 코드가 문제인지 일단 구분이 가능하기 때문에 문제를 더 좁혀서 찾아낼 수 있답니다!

Q5. 8주차 느낀 점

  테스트 코드를 처음 배우는 사람이 회사 다니면서 일주일만에 할 수 있는 과제인가? 저는 절대 아니라고 생각합니다. 그럼에도 이번 과제가 저에게 의미있었던 부분은 테스트 코드의 첫 삽을 떴다는 점입니다. 아무 것도 안 하면 성장할 수 없고 무엇을 해야할 지 모르면 아무 것도 할 수 없습니다. 이 굴레에서 벗어나기 위해 항해 플러스를 선택했고 이번 10주 과정을 기점으로 앞으로 더 성장해나갈 수 있을 것이라는 확신을 갖게 되었습니다!