게시물 업데이트

2021/02/09 : RTL을 활용한 테스트 (+ Axios Mockup 테스트)
2021/05/05: Axios Mockup 테스트 추가 포스팅

실습 Repository :https://github.com/LeeHyungi0622/react_testing_library_mock_axios_request_practice_repo

React Testing Library 설치

1

$ npm install --save-dev @testing-library/react

RTL(React-Testing-Library)는 모든 테스트를 DOM 위주로 한다. 별도로 props나 state를 조회하는 테스트는 하지 않는다. 그 이유는 컴포넌트를 리팩토릴할때 내부 구조와 네이밍은 많이 바뀔 수 있어도 실제 동작방식은 크게 바뀌지 않기 때문이다.
따라서 RTL에서는 컴포넌트의 기능이 똑같이 동작한다면, 컴포넌트의 내부 구현 방식이 바뀌어도 실패하지 않도록 테스트를 지원한다.

• DOM 시뮬레이션은 JSDOM이라는 도구를 사용하여 document.body에 React 컴포넌트를 렌더링한다.

• @testing-library/jest-dom 은 DOM관련 matcher를 사용할 수 있게 지원해주는 라이브러리이다.

snapshot 테스트

1
2
3
4
5
6
7
8
9
10

import { render } from '@testing-library/react';
import Profile from './Profile';

describe('<Profile /> 컴포넌트 테스트', () => {
  test('snapshot 테스트',() => {
    const snapshot = render(<Profile surname="lee", givenname="hyungi" />);
    // container는 검사하는 컴포넌트의 최상위 DOM을 가르킨다.
    expect(snapshot.container).toMatchSnapshot();
  });
});

요 몇일동안 아니 저번달도 몇 일정도 이 TDD라는 녀석에 대해서 검색도 해보고, 영상도 보고 나름 이것저것 시행착오를 겪어가며 공부를 하였다.

처음에는 요즘 트렌드라고 하니깐, 그리고 완벽하게는 아니지만, 개발 도중에 발생하는 대다수의 버그를 잡아낼 수도 있다는 이야기를 듣고 무작정 해보려고 테스트 코드 작성법부터 찾아보았다. 하지만 왠지 제대로 작성하고 있는건지 의문이 들었었다.

그래서 그때부터 이론적인 부분부터 실무에서 직접 적용해 본 실무자들이 올린 블로그 글, 유뷰트 관련 영상 등등 이 곳 저 곳에 흩어져 있는 알짜배기 내용들을 읽고 정리하고 연습하기를 반복하였다.

가장 도움이 되었던 블로그 글은 네이버 기술 블로그에 프론트엔드 개발자 분이 올려주신 TDD관련 내용이었다. 그 분의 글을 보면서 실무에서는 어떤 방식으로 테스트 코드를 작성하고 어떤 테스트가 좋은 테스트인지에 대해서도 자세하게 알 수 있었다. 너무 내용이 좋아서 노트 필기를 하며 읽어 보았는데, 나중에 한 번 더 보고 싶을 때 참고할 수 있게 아래에 필기내용을 첨부하였다.

좋은 테스트의 조건과 효과

좋은 테스트란 무엇일까? 무작정 테스트 코드를 작성해보려고 했지만 막상 좋은 테스트란 무엇인지 알지 못했다.

우선 첫 번째, 테스트의 의도가 명확해야 한다. 코드의 가독성은 중요하다. 좋은 코드는 기계가 아닌 사람이 읽기 쉬워야 한다. 누군가 내가 작성한 테스트 코드를 보았을때 한 눈에 어떤 내용을 테스트하고 있는지 파악할 수 있어야 한다. 테스트 코드가 너무 장황해지거나 불필요하게 복잡해진다면 별도의 함수를 만들어 추상화시켜주는 것이 좋다.

두 번째, 좋은 테스트란 빠른 피드백을 받을 수 있으며, 개발 속도를 빠르게 할 수 있도록 해야 한다. 테스트 결과를 보기 위해 오랫동안 기다려야 하는 테스트는 개발 과정에서 좋지 않다.

TDD방식으로 React 개발하기 위한 연습 프로젝트

test의 필요성

1. documentation (문서화 작업)
   테스트 코드는 코드가 어떻게 동작을 해야 되는지에 대한 정의를 하고 있다.

2. consistency (지속성)
   Software developer들이 팀을 위한 최선의 practices와 conventions을 따를 수 있게 도와준다.

3. Confidence (자신감)
   warm blanket 코드를 작성할때 좀 더 자신감 있게 코드를 작성할 수 있도록 도와준다.

4. Productivity (생산성)
   테스트는 높은 품질의 코드를 빠르게 작성할 수 있도록 도와준다

Bundle size와 Lazy loading

React routing test를 하면서 각 각의 Component를 lazy loading하여 테스트를 진행하였다.

이 lazy loading(지연로딩)에 대해서 좀 더 자세하게 알아두고자 포스팅으로 정리를 해둔다.

React app의 크기가 커짐에 따라 개발자는 bundle size에 대한 걱정을 시작해야 할 수 있다. 이 bundle size란 사용자가 React app을 load하기 위해 download해야만 하는 JavaScript의 양을 의미한다.
이 Bundle size가 클수록 사용자가 app으르 보는데 시간이 오래걸린다.

따라서 이 Lazy를 사용해서 component가 rendering 될때에 사용되지 않는 구성요소에 대한 로드를 지연시킬 수 있다.

React Router Test

이번 포스팅에서는 React router testing에 대해서 정리해보려고 한다.
React router test파일은 <App/> component에 대한 test file을 작성한다.

• 우선 기본적으로 작성할 테스트 케이스의 내용을 정리해보자.

  • (Test case 1) 처음 <App/> component가 rendering될때 root path와 matching되는 Home component가 rendering되는가?
  • (Test case 2) <nav> 태그로 만든 각 menu를 클릭했을때 각 각의 matching되는 component로 rendering이 되는가?
  • (Test case 3) route에 해당하는 path가 없는 경우에는 404 Not Found component가 rendering되는가?
  • (Test case 4) 페이지가 loading되는 동안 <Loading /> component가 페이지가 표시되는가?

  Test case 4의 Loading component가 DOM에 그려지는 것을 확인하기 위해서 component를 Lazy하게 가져와야 한다.