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 (생산성)
   테스트는 높은 품질의 코드를 빠르게 작성할 수 있도록 도와준다

TDD?

이번 포스팅에서는 TDD에 대해서 정리를 해보려고 한다.

우선 TDD란 Test Driven Development의 약어로 테스트 주도 개발을 의미한다.
즉, 테스트가 개발을 이끌어 나가는 형태의 개발론이다.
이 TDD방식의 개발은 선 Test code 작성, 후 구현을 의미하며, 총 3가지 (실패, 성공, 리팩토링)의 절차로 구성된다. 구체적인 내용에 대해서는 테스트 자동화(Automated Testing)와 테스트의 종류에 관련된 내용을 우선 정리하고 정리해보도록 하겠다.
우선 개발에서 테스트의 정의는 내가 작성한 코드가 잘 작동한다는 것을 검증하는 단계이다. 가장 기본적으로 만들어진 어플리케이션을 테스트하는 방법은 직접 마우스와 키보드를 사용해서 의도대로 잘 동작하는지 확인할 수 있다.
하지만 이렇게 모든 기능을 사람 손으로 하나하나 확인하는 것은 여간 번거로운 일이 아닐 수 없다.

그래서 테스트 코드라는 것을 작성해서 테스트를 자동화시켜준다. 테스트 자동화란 사람이 직접 어플리케이션의 동작을 확인하는 것이 아닌, 작성한 테스트 코드를 통해서 테스트 시스템이 자동으로 확인을 해주는 것을 말한다.

테스트 자동화(Automated Testing)

• 테스트 자동화의 장점

  • 여러 사람들과 협업하여 작업을할때 각자가 작성한 코드에 문제가 있는지 빠르게 검사를 할 수 있다.
  • 새로운 기능을 추가하는 작업의 경우, 기존의 기능들을 망가뜨리는 것을 사전에 방지할 수 있다.
  • 테스트 코드를 적는다는 것은 개발할때 실제 발생할 수 있는 상황에 대하여 미리 정리해놓는 일련의 작업이기 때문에 미리 정리해놓고 그에 상응하는 코드를 작성하게 되면 필요한 사항들을 까먹지 않고 넣어줄 수 있다.
  • Code Refactoring시에도 좋다. 일부 기능에 대한 코드를 리팩토링할때 기존에 이 기능에 대한 테스트 코드가 존재한다면 리팩토링한 후에도 동일한 동작을 하는지 검사하면 되기 때문에 검증하기가 쉽다.