React Test Library (RTL)
- 사용자 사용방식으로 소프트웨어 테스트
- 내부 구현 테스트를 대신하기 (소프트웨어 작동법)
둘 다 소프트웨어가 정상적으로 작동하는지에 대한 테스트를 진행.
작성한 코드의 구조적인 변경이 있더라도 테스트가 정상적으로 통과된다면 옳바른 코드임을 보증.
접근성 마커 (Accessibility markers) 로 요소를 찾는다.
접근성 마커로 요소를 찾을 수 있다면 스크린 리더로도 가능하고,
소프트웨어에 액세스가 가능하다는 의미.
RTL vs Jest
RTL 은 테스트를 위한 가상 DOM 을 제공한다.
브라우저 없이 테스트를 진행하면 클릭 요소와 같은 작업을 할 때 가상 DOM 이 필요하다.
Jest 는 일종의 테스트 러너이다.
테스트를 찾고 실행하는 것과 테스트 통과 여부를 결정하는 역할을 한다.
First Test
CRA 를 통해 프로젝트를 생성한 후 yarn test(npm test) 를 터미널에 입력하면
아래와 같은 콘솔 화면이 나온다.
No tests found related to files changed since last commit.
Press `a` to run all tests, or run Jest with `--watchAll`.
Watch Usage
› Press a to run all tests.
› Press f to run only failed tests.
› Press q to quit watch mode.
› Press p to filter by a filename regex pattern.
› Press t to filter by a test name regex pattern.
› Press Enter to trigger a test run.
a 키를 입력하면 모든 테스트를 실행하게 되는데
PASS src/App.test.tsx
✓ renders learn react link (15 ms)
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 0.93 s
Ran all test suites.
CRA 에서 기본적으로 제공하는 app.test 파일에 대한 테스트가 성공적으로 완료되었다는
메시지를 출력한다.
import { render, screen } from '@testing-library/react';
import App from './App';
test('renders learn react link', () => {
render(<App />);
const linkElement = screen.getByText(/learn react/i);
expect(linkElement).toBeInTheDocument();
});CRA 를 통한 앱 빌드 이후에 가장 기본적으로 제공하는 app.test.tsx 파일.
해당 파일을 살펴보면 render, screen 메소드를 사용하는 것을 볼 수 있다.
render 메소드는 첫번째 인자로 받은 JSX 에 대한 가상 DOM을 생성한다.
이후 렌더링 된 가상 DOM 에 scrren global 객체의 getByText 메소드로
스크린에 표시되는 텍스트에 접근한다. 위의 예시는 정규식을 이용해 검사한다.
그 다음 expect 메소드를 이용해 테스트의 성공 혹은 실패를 단언한다.
위의 getByText의 인자로 들어갈 텍스트를 바꾸고 yarn test 명령어를 실행하면,
5 | test('renders learn react link', () => {
6 | render(<App />);
> 7 | const linkElement = screen.getByText(/learn testing library/i);
| ^
8 | expect(linkElement).toBeInTheDocument();
9 | });
10 |
at Object.getElementError (node_modules/@testing-library/dom/dist/config.js:37:19)
at node_modules/@testing-library/dom/dist/query-helpers.js:76:38
at node_modules/@testing-library/dom/dist/query-helpers.js:52:17
at getByText (node_modules/@testing-library/dom/dist/query-helpers.js:95:19)
at Object.<anonymous> (src/App.test.tsx:7:30)
at TestScheduler.scheduleTests (node_modules/@jest/core/build/TestScheduler.js:333:13)
at runJest (node_modules/@jest/core/build/runJest.js:404:19)
Test Suites: 1 failed, 1 total
Tests: 1 failed, 1 total
Snapshots: 0 total
Time: 0.831 s, estimated 1 s
Ran all test suites related to changed files.어느 부분의 테스트가 실패했는지 테스트 코드를 통해서 명시해준다.
Jest 와 Assertion
jest 의 전역 메소드인 expect 메소드는 테스트 함수의 핵심 부분이며 '단언' 의 역할을 한다.
인자로 들어갈 대상에 대해 예측 및 분석을 진행한다.
이후 matcher 를 이용해 '단언의 유형'을 처리한다.
Jest 의 동작원리
RTL 은 컴포넌트를 가상 dom 으로 렌더링하거나, 검색하거나, 상호작용하여 요소를 클릭하거나
텍스트를 입력하는 등의 역할을 한다.
이러한 테스트를 찾고 실행하며 '단언' 해줄 수 있는 도구가 Jest 이다.
테스팅 라이브러리는 여러 종류가 있지만 Jest 를 CRA 환경에서 기본적으로 제공하기도 하고
권장하고 있다.
Jest 의 Watch 모드
마지막 커밋 이후 파일의 모든 변경사항을 확인해서
마지막 커밋 이후 변경된 파일과 연관된 테스트만 실행한다.
예를들어, 위의 테스트를 진행한 이후에 commit 분기가 없다면
정상적으로 테스트를 통과하더라도
PASS src/App.test.tsx
✓ renders learn react link (9 ms)
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 0.221 s, estimated 1 s
Ran all test suites related to changed files.
Watch Usage: Press w to show more.test 를 진행했을 때 1 passed, 커밋 시점 이후의 변경사항을 테스트 한다.
커밋을 한 이후에는
No tests found related to files changed since last commit.
Press `a` to run all tests, or run Jest with `--watchAll`.
Watch Usage
› Press a to run all tests.
› Press f to run only failed tests.
› Press q to quit watch mode.
› Press p to filter by a filename regex pattern.
› Press t to filter by a test name regex pattern.
› Press Enter to trigger a test run.
commit 이후에 파일 변경이 없다는 문구를 출력한다.
쉽게 생각하자면 세이브 포인트 갱신 같은 느낌.
TDD (Test Driven Development)
흔히 테스트 주도 개발이라고 한다. 레드-그린 테스팅 이라고도 한다.
코드 작성 전에 테스트를 작성하고 테스트에 통과하도록 코드를 작성하는 것.
보통은 다음과 같은 순서를 따른다.
- 빈 함수, 구현물이 없는 함수(컴포넌트)를 정의한다.
- 테스트 코드를 작성한다.
- 구현물이 없는 함수에 대한 테스트는 실패한다. --- 레드 구간
- 테스트를 통과할 수 있는 코드를 구현한다.
- 테스트를 통과하는 코드를 구현했다면 TDD ! --- 그린 구간
TDD 를 하는 이유 ?
테스트가 코딩 프로세스의 일부분이 되기 때문이다.
애플리케이션을 일일히 실행하면서 확인하는 수동 테스트가 아닌
테스트 코드 기반의 테스트를 통한 자동 테스트가 가능하다.
변경 사항이 있을 때마다 자동으로 테스트가 되기 때문에 리펙토링과 코드 구조 변경에 자유롭다.
유닛 테스트 vs 기능 테스트
유닛 테스트는 소프트웨어의 가장 작은 단위, 즉 "유닛"을 테스트하는 과정이다.
보통 이 "유닛"은 하나의 함수나 메소드를 말하는데, 유닛 테스트의 목적은
코드의 개별 부분이 예상대로 동작하는지 확인하는 것이다.
모든 입력과 출력을 검사하고 예외 상황을 처리해야 한다.
기능 테스트는 소프트웨어의 특정 기능이 사용자의 기대에 부합하게 동작하는지를 확인하는 과정이다.
사용자 관점에서 시스템의 기능을 테스트하며, 사용자 인터페이스, 데이터베이스,
클라이언트/서버 애플리케이션 등에 이르기까지 모든 구성 요소가 연동되어 잘 작동하는지
확인하는 역할을 한다. 기능 테스트는 사용자 스토리나 요구 사항을 기반으로 시나리오를 개발하며, 시나리오를 통해 테스트가 진행된다.
종종 종합 테스트(Integration Test)와 비슷한 성격을 가진다.
