테스팅
테스트의 이유
간단하게 더 안정적인 어플리케이션을 위해서는 여러 방법으로 테스트를 해줘야 더 안정적인 어플리케이션을 완성할 수 있다.
테스팅의 이점
-
디버깅 시간 단축
만약 데이터가 잘못 나왔다면
UI 문제인지 DB문제인지 등 전부 테스트해서 찾아봐야하는데,
테스팅 환경이 구축되어있다면
자동화된 유닛 테스팅으로 특정 버그를 쉽게 찾아낼 수 있다. -
더욱 안정적인 어플리케이션
많은 테스트 코드와 함께 작성된 코드의 어플리케이션이 되기 때문에
훨씬 안정적인 어플리케이션이 된다. -
재설계 시간 단축, 추가 구현 용이
TDD
Test Driven Development
실제 코드를 작성하기 전에 테스트 코드를 먼저 작성한다.
테스트 코드를 작성한 후 그 테스트 코드를 Pass 할 수 있는 실제 코드를 작성한다.
- 원하고자하는 기능의 테스트 코드 작성
- 테스트 실행 Fail
- 테스트 코드에 맞는 실제 코드 작성
- 테스트 실행 Pass
TDD의 이점
- 많은 기능을 테스트하기에 소스 코드에 안정감이 부여된다.
- 실제 개발하면서 많은 시간이 소요되는 부분은 디버깅 부분이기에 TDD를 사용하면 디버깅 시간이 줄어들고 실제 개발 시간도 줄어든다.
- 소스 코드 하나하나를 더욱 신중하게 짤 수 있기 때문에 깨끗한 코드가 나올 확률이 높다.
React Testing Library
Create React App으로 리액트 앱을 생성하면
기본적으로 테스팅할 때 React Testing Library를 사용하는 것을 볼 수 있다.
React Testing Library는 React 구성 요소 작업을 위한 API를 추가하여 DOM Testing Library 위에 구축된다.
DOM Testing Library란 DOM 노드(Node)를 테스트하기 위한 매우 가벼운 솔루션이다.
Create React App으로 생성된 프로젝트는 즉시 React Testing Library를 지원한다. 만약 그렇지 않을 경우 npm install --save dev @testing-library/react로 추가할 수 있다.
React 구성 요소를 테스트하여
React 구성 요소를 완전히 신뢰하는 방법에 대해 질문한다.
구성 요소의 구현 세부 정보를 테스트하는 대신
React Testing Library 개발자를 React 애플리케이션의 사용자 입장에 둔다.
행위 주도 테스트 (Behavior Driven Test)
Jest
Jest
FaceBook에 의해서 만들어진 테스팅 프레임 워크
최소한의 설정으로 동작하며 Test Case를 만들어서 어플리케이션 코드가 잘 돌아가는지 확인한다.
단위 (Unit) 테스트를 위해서 이용한다.
Jest 시작하기
- Jest 라이브러리 설치
npm install jest --save-dev - Test 스크립트 변경
"test" : "jest"or"jest --watchAll" - 테스트 작성할 폴더 및 파일 기본 구조 생성
- 단위 테스트 폴더 (Unit Test) -> 단위 테스트 파일 <대상 이름>.test.js
- 통합 테스트(Integration Test) -> 통합 테스트 <대상 이름>.test.init.js
Jest가 Test 파일을 찾는 방법
{filename}.test.js
{filename}.spec.js
All files inside "tests" folders
Jest 파일 구조 & 사용법
describe
argument (name, fn)
여러 관련 테스트를 그룹화하는 블록을 만든다.
it same as test
argument (name, fn, timeout)
개별 테스트를 수행하는 곳
각 테스트를 작은 문장처럼 설명한다.
expect
expect 함수는 값을 테스트할 때마다 사용된다.
혼자서는 거의 사용되지 않으며 matcher와 함께 사용된다.
matcher
다른 방법(toBe 등)으로 값을 테스트하도록 매처를 사용한다.
React Testing Library 주요 API
render 함수
DOM 에 컴포넌트를 렌더링하는 함수
인자로 렌더링할 React 컴포넌트가 들어감
Retrun은 RTL에서 제공하는 쿼리 함수와 기타 유틸리티 함수를 담고 있는 객체를 리턴
(Destructuring 문법으로 원하는 쿼리 함수만 얻어올 수 있다.)
-> 소스 코드가 복잡해지면 비추천 , screen 객체를 사용하기
왜냐하면 사용해야 할 쿼리가 많아질수록 코드가 복잡해질 수 있음
쿼리 함수
쿼리는 페이지에서 요소를 찾기 위해 테스트 라이브러리가 제공하는 방법
여러 유형의 쿼리(get, find, query)가 있다.
차이점은 요소가 발견되지 않으면 쿼리에서 오류가 발생하는지 또는 Promise를 반환하고 다시 시도하는지 여부이다.
선택하는 페이지 콘텐츠에 따라 다른 쿼리가 다소 적절할 수 있다.
getBy
쿼리에 대해 일치하는 노드를 반환하고 일치하는 요소가 없거나 둘 이상의 일치가 발견되면 오류를 발생시킨다.
둘 이상의 요소가 예상되는 경우 대신 getAllBy 사용
queryBy
쿼리에 대해 일치하는 노드를 반환하고 일치하는 요소가 없으면 null을 반환한다.
이것은 존재하지 않는 요소를 어설션하는 데 유용하다.
둘 이상의 일치 항목이 발견되면 오류를 발생한다.
확인된 경우 대신 queryAllBy 사용
findBy
주어진 쿼리와 일치하는 요소가 발견되면 해결되는 Promise를 반환한다.
요소가 발견되지 않거나 기본 제한 시간의 1000ms 후에 둘 이상의 요소가 발견되면 약속이 거부된다.
둘 이상의 요소를 찾아야 하는 경우 findAllBy를 사용
waitFor
일정 기간 동안 기다려야할 때 waitFor를 사용하여 기대가 통과할 때까지 기다릴 수 있다.
