해당 글은 John Ahn 님의 따라하는 리액트테스트 강의를 참고하여 작성했습니다.
왜 애플리케이션을 TEST 해야 할까요?
간단하게 더 안정적인 애플리케이션을 위해서는 여러 방법으로 테스트를 해줘야 더 안정적인 애플리케이션이 될 수 있습니다.
테스팅으로 얻는 이점은 무엇일까요?
- 디버깅 시간을 단축! 만약 데이터가 잘못 나왔다면 그것이 UI의 문제인지 DB의 문제인지등 전부 테스트를 해봐서 찾아야 하는데 테스팅 환경이 구축된 어있다면 자동화된 유닛 테스팅으로 특정 버그를 쉽게 찾아낼 수 있습니다.
- 더욱 안정적인 애플리케이션! 많은 테스트 코드와 함께 작성된 코드의 애플리케이션이 되기 때문에 훨씬 안정적인 애플리케이션이 됩니다.
- 이밖에도 재설계 시간의 단축과 추가로 무언가를 더 구현해야 할 때 더 용이하게 할 수 있는 등의 이점들이 있습니다. 만약 등록하기 버튼의 이벤트 핸들러 함수에 A, B, C의 유틸성 함수가 모여있는 상태에서 D 기능을 추가해야 된다면 결괏값이 달라지는 경우가 있는데 이때 테스트 코드가 있다면 지뢰 찾기 게임의 깃발을 꽂듯이 버그의 위험성을 미리 감지할 수 있습니다.
React Testing Library란 무엇인가요?
React Testing Library는 React 구성 요소 작업을 위한 API를 추가하여 DOM Testing Library 위에 구축됩니다. DOM Testing Library란 Dom 노드(Node)를 테스트하기 위한 매우 가벼운 설루션입니다.
Create React App으로 생성된 프로젝트는 즉시 React Testing Library를 지원합니다. 그렇지 않은 경우 다음과 같이 npm을 통해 추가할 수 있습니다.
npm install --save-dev @testing-library/react
React Testing Library는 에어비앤비에서 만든 Enzyme(엔자임)을 대처하는 설루션입니다.
- React Testing Library와 Enzyme(엔자임) 차이
- Testing 철학:
- React Testing Library: React Testing Library는 테스트 작성자가 애플리케이션을 사용자 관점에서 테스트하는 것을 강조합니다. 즉, 컴포넌트의 내부 상태나 메서드에 의존하는 것보다 실제 사용자가 상호작용하는 방식으로 컴포넌트를 테스트하는 것이 주요 목표입니다.
- Enzyme: Enzyme는 컴포넌트의 내부 구조와 상태에 대한 접근을 허용하며, 보다 컴포넌트의 내부 동작을 직접 테스트하기 위해 사용됩니다. 이는 컴포넌트의 인스턴스를 조작하고 감시할 수 있음을 의미합니다.
- API 및 사용법:
- React Testing Library: React Testing Library는 컴포넌트를 렌더링 하고 실제 DOM 요소를 검색하거나 상호작용하는 데 사용하는 매우 단순한 API를 제공합니다. 주로
render()
,fireEvent()
,screen.getBy*()
와 같은 메서드를 사용합니다. - Enzyme: Enzyme은 컴포넌트의 인스턴스에 대한 더 많은 제어를 제공하며,. find(),. simulate(),. state() 등과 같은 메서드를 사용하여 컴포넌트의 내부를 테스트합니다.
- React Testing Library: React Testing Library는 컴포넌트를 렌더링 하고 실제 DOM 요소를 검색하거나 상호작용하는 데 사용하는 매우 단순한 API를 제공합니다. 주로
- 유지보수와 테스트 유지:
- React Testing Library: React Testing Library는 사용자 관점에서 테스트를 작성하기 때문에 컴포넌트의 내부 구현에 대한 변경에 덜 민감하며, 테스트의 유지보수가 비교적 쉬울 수 있습니다.
- Enzyme: Enzyme은 컴포넌트의 구현에 더 의존하기 때문에 컴포넌트 변경 시 테스트 코드를 더 자주 수정해야 할 수 있습니다.
- 커뮤니티와 생태계:
- React Testing Library: React Testing Library는 React 생태계와 통합이 더 쉽고, React 팀에서도 권장하는 테스트 라이브러리입니다. 많은 개발자와 기업에서 사용하고 있으며 커뮤니티가 활성화되어 있습니다.
- Enzyme: Enzyme은 예전부터 사용해 온 라이브러리이며, 일부 프로젝트에서는 여전히 사용되고 있지만 React Testing Library나 다른 테스트 라이브러리로의 이전도 진행 중인 곳도 있습니다.
- Testing 철학:
DOM 이란?
앞서 React Testing Library를 설명할 때 DOM에 관한 설명이 나와서 DOM에 대해서 좀 더 자세히 알아봐야 합니다.
DOM(문서 객체 모델)은 XML, HTML 문서의 각 항목을 계층으로표현하여 생성, 변형 삭제할 수 있도록 돕는 인터페이스이다. - 위키피디아
웹 페이지 빌드 과정(Critical Rendering Path CRP)
브라우저가 서버에서 페이지에 대한 HTML 응답을 받고 화면에 표시하기 전에 여러 단계가 있습니다.
웹 브라우저가 HTML 문서를 읽고, 스타일 입히고 뷰포트에 표시하는 과정입니다
- (HTML, CSS) + javascript: 문서를 읽어 들여서 그것들을 파싱하고 어떤 내용을 페이지에 렌더링 할지 결정합니다
- Render Tree: 이 단계는 브라우저가 DOM과 CSSOM을 결합하는 곳이며, 이 프로세스는 화면에 보이는 모든 콘텐츠의 콘텐츠와 스타일 정보를 모두 포함하는 최종 렌더링 트리를 출력합니다. 즉 화면에 표시되는 모든 노드의 콘텐츠 및 스타일 정보를 포함합니다.
- Layout: 이 단계는 브라우저가 페이지에 표시되는 각 요소의 크기와 위치를 계산하는 단계입니다.
- Paint: 페인트 단계에 도달하면 브라우저는 레이아웃 결과를 선택하고 픽셀을 화면에 페인트해야 합니다.
DOM(문서 객체 모델, Document Object Model)은 웹 페이지의 구조를 프로그래밍 방식으로 표현하고 조작할 수 있게 해주는 인터페이스입니다. DOM은 웹 브라우저에서 웹 페이지를 로드하면서 생성되며, 웹 페이지의 모든 요소와 그들 간의 관계를 나타내는 트리 구조로 이루어져 있습니다. HTML 문서가 유효하지 않게 작성됐을 때는 브라우저가 올바르게 교정해 주며, DOM은 자바스크립트에 의해 수정될 수 있습니다. 하지만 HTML은 수정하지 않습니다.
Jest에 대하여
Jest는 FaceBook에 의해서 만들어진 테스팅 프레임 워크입니다. 최소한의 설정으로 동작하며 Test Case를 만들어서 애플리케이션 코드가 잘 돌아가는지 확인해 줍니다. 보통 단위(Unit) 테스트를 위해서 이용합니다
Jest가 Test 파일을 찾는 방법: tests폴더에 있거나,. test.js,. spec.js처럼 중간 확장자에 test나 spec가 붙은 파일
Jest파일구조
- describe: 여러 관련 테스트를 그룹화하는 블록을 만듭니다.
- it: 개별 테스트를 수행하는 곳. 각 테스트를 작은 문장처럼 설명합니다.
- expect: expect 함수는 값을 테스트할 때마다 사용됩니다. 그리고 expect 함수 혼자서는 거의 사용되지 않으며 matcher와 함께 사용됩니다
- matcher: 다른 방법으로 값을 테스트하도록 "매처"를 사용합니다. (toBe, toStrictEqual, toBeTruthy)
간단한 테스트 진행
//__test__/page.test.tsx 작성
describe("HomePage 테스트", () => {
it("renders Page", () => {
const { getByText } = render(<Home />);
const linkElement = getByText(/Next.js Tailwind CSS/i);
expect(linkElement).toBeInTheDocument();
});
});
// jest 실행
yarn test
// 모든 테스트 코드 재실행
a
- render 함수: DOM에 컴포넌트를 랜더링 하는 함수 인자로 랜더링 할 React 컴포넌트가 들어감 Return은 RTL에서 제공하는 쿼리 함수와 기타 유틸리티 함수를 담고 있는 객체를 리턴(Destructuring 문법으로 원하는 쿼리 함수만 얻어올 수 있다.) ====> 소스 코드가 복잡해지면 비추천!!! screen 객체를 사용하기
왜냐면 사용해야 할 쿼리가 많아질수록 코드가 복잡해질 수 있음
쿼리 함수란?
쿼리는 페이지에서 요소를 찾기 위해 테스트 라이브러리가 제공하는 방법입니다. 여러 유형의 쿼리("get", "find", "query")가 있습니다. 이들 간의 차이점은 요소가 발견되지 않으면 쿼리에서 오류가 발생하는지 또는 Promise를 반환하고 다시 시도하는지 여부입니다. 선택하는 페이지 콘텐츠에 따라 다른 쿼리가 다소 적절할 수 있습니다
get, find, query의 차이점
- getBy: 쿼리에 대해 일치하는 노드를 반환하고 일치하는 요소가 없거나 둘 이상의 일치가 발견되면 설명오류를 발생시킵니다(둘 이상의 요소가 예상되는 경우 대신 getAllBy 사용)
- queryBy: 쿼리에 대해 일치하는 노드를 반환하고 일치하는 요소가 없으면 null을 반환합니다. 이것은 존재하지 않는 요소를 어설션하는데 유용합니 다. 둘 이상의 일치 항목이 발견되면 오류가 발생합니다(확인된 경우 대
신 queryAllBy 사용) - findBy: 주어진 쿼리와 일치하는 요소가 발견되면 Promise를 반환합니다. 요소가 발견되지 않거나 기본 제한 시간인 1000ms후에 둘 이상의 요소가 발견되면 약속이 거부됩니다. 둘 이상의 요소를 찾아야 하는 경우 findAllBy를 사용하십시오.
- waitFor: 일정 기간 동안 기다려야 할 때 waitFor를 사용하여 기대가 통과할 때까지 기다릴 수 있습니다.
'기억보단 기록을 > Next JS (App Router)' 카테고리의 다른 글
NextJS 테스트 코드 작성하기 - 간단한 앱 만들면서 테스트 코드 작성 해보기 (0) | 2023.09.14 |
---|---|
NextJS 테스트 코드 작성하기 - NextJS 테스트를 위한 모듈 설치 및 설정 (0) | 2023.09.13 |
[NextJS 13] Routing - Middleware (0) | 2023.06.26 |
[NextJS 13] Routing - Route Handlers & 활용방안 (0) | 2023.06.25 |
[NextJS 13] Routing - Intercepting Routes(라우트 가로채기) (0) | 2023.06.12 |