프론트엔드 테스트 코드 시작하기 - 개념편

목차

1. Goal
2. What do you want to test
3. Types of tests
   1. End to End test
   2. Integration test
   3. Unit test
   4. Static test
4. Project
   1. Prerequisites
   2. Init
   3. Installation
      1. jest
      2. ts-node
   4. set the config
   5. Add script on package.json
   6. Initialize the test jsdom environment
   7. Sumaary
   8. results
   9. etc
5. 레퍼런스

1) Goal

1. 정확성 및 신뢰성 확보
   1. 테스팅의 주요 목적은 코드가 올바르게 작동하는지 확인하는 것
   2. 다양한 조건 및 입력에서 리액트 컴포넌트가 예상대로 동작하는지 확인하는 것
2. 수월한 리팩터링
   1. 프로젝트가 성장하면 리팩터링이 필요함
      1. 코드 품질, 성능개선, 새로운 패턴 적용 등
   2. 테스트코드 작성으로 통과해야 하는 최소한의 기준이 만들어짐
   3. 변경사항 또는 최적화가 예상치 못한 버그를 만들지 않도록

2) What do you want to test?

우리는 비지니스 로직을 테스트해야 한다

1. 코드가 잘 “동작” 하는지를 확인하기 위한 테스트 (유저의 이벤트 기반의 테스트)
2. 버튼을 클릭했을 때 내가 의도한 대로 잘 동작하는지?
   • 로그인 성공 시 내가 원하는 화면으로 리다이렉션이 되는지
   • 로그인 실패 시 내가 원하는 에러메시지가 나오는지

3) Types of tests

당신은 무엇을 테스트하고 싶으신가요? 최근 테스트의 유형을 정적/단위/통합/E2E 테스트로 나눠볼 수 있습니다. 아래는 Kent. C. Dodds가 정의한 테스팅 트로피입니다.

 

[이미지 레퍼런스 - https://kentcdodds.com/blog/the-testing-trophy-and-testing-classifications]

3-1) End to End (E2E 테스트)

End to End (E2E 테스트)는 사용자 경험을 시뮬레이션하는 테스트 방법입니다. 이 테스트는 실제 사용자가 시스템을 사용하는 것처럼 작동하며, 사용자 인터페이스(UI)를 통해 시스템의 모든 부분을 테스트합니다. E2E 테스트는 브라우저 또는 기타 클라이언트 애플리케이션을 통해 소프트웨어를 테스트하므로 실제 사용자 환경과 가장 유사합니다. 이는 소프트웨어의 모든 컴포넌트가 함께 작동하는 방식을 확인하며, 통합 테스트 후에 일반적으로 수행됩니다.

 

E2E 테스트는 대부분의 경우 실제 사용자 시나리오를 반영하도록 설계되어 있으며, 여러 컴포넌트와 서비스가 서로 상호작용하는 방식을 테스트하는 데 특히 유용합니다. 사용자의 관점에서 시스템을 테스트함으로써, 단순히 개별 컴포넌트가 기능하는지를 넘어 전체 시스템이 원활하게 작동하는지 확인할 수 있습니다.

 

E2E 테스트는 테스트 자동화 도구를 사용하여 수행되며, 이 도구들은 실제 사용자가 웹사이트 또는 애플리케이션을 사용하는 것처럼 클릭하고 입력하고 스크롤하는 등의 작업을 자동으로 수행합니다. 이로 인해 사용자가 겪을 수 있는 실제 상황과 문제를 재현하고 식별할 수 있습니다.

 

그러나 E2E 테스트는 설계와 유지 관리가 비교적 어렵고 시간이 많이 소요되는 단점이 있습니다. 따라서 이러한 테스트는 전체 테스트 전략의 일부로 사용되어야 하며, 단위 테스트와 통합 테스트와 같은 다른 유형의 테스트와 함께 사용되어야 합니다.

3-2) Integration (통합 테스트)

통합 테스트는 소프트웨어의 개별 모듈이 서로 올바르게 작동하는지 확인하는 테스트 방법입니다. 이는 단위 테스트가 아닌 여러 단위들이 결합하여 작동하는지 확인합니다. 통합 테스트는 각 단위 간의 통신, 데이터 교환, 연계 등을 확인하며, 이는 전체 시스템의 안정성과 신뢰성을 높이는 데 중요한 역할을 합니다. 또한, 통합 테스트는 실제 사용자 환경과 가장 유사한 테스트 환경에서 수행되며, 실제 시스템 운영에 필요한 다양한 요소를 테스트할 수 있습니다.

 

통합 테스트가 중요한 이유 중 하나는 개별 모듈이 아니라 여러 모듈이 서로 상호작용하는 방식을 확인하기 때문입니다. 예를 들어, 데이터베이스와 웹 서버, 웹 서버와 클라이언트 애플리케이션 간의 상호작용을 테스트할 수 있습니다. 이로 인해 각 모듈이 독립적으로 작동할 때는 문제가 없어 보일 수도 있지만, 실제로는 다른 모듈과의 상호작용에서 문제가 발생할 수 있다는 사실을 발견할 수 있습니다.

 

또한, 통합 테스트는 실제 시스템 운영 환경에서 발생할 수 있는 여러 문제를 미리 파악하고 대비할 수 있게 해 줍니다. 예를 들어, 서로 다른 시스템 간의 데이터 형식 불일치, 시간 지연, 서버 다운 등의 문제를 미리 파악하고 대응할 수 있습니다. 이러한 문제들은 개별 모듈만을 테스트할 때는 발견하기 어렵지만, 통합 테스트를 통해 미리 발견하고 대응할 수 있습니다.

 

따라서 통합 테스트는 전체 시스템의 안정성과 신뢰성을 높이는 데 매우 중요한 역할을 합니다. 하지만 통합 테스트만으로는 충분하지 않으며, 단위 테스트와 E2E 테스트와 같은 다른 유형의 테스트와 함께 사용돼야 합니다.

3-3) Unit (단위 테스트)

단위 테스트(Unit Test)는 소프트웨어의 가장 작은 단위인 함수, 메서드, 클래스, 모듈 등이 예상대로 작동하는지 확인하는 테스트 방법입니다. 이러한 단위 테스트는 코드의 각 부분이 정확하게 작동하며, 예상대로 결과를 반환하는지 검사합니다. 이는 전체 시스템의 안정성과 신뢰성을 높이는 데 중요한 역할을 합니다. 또한, 단위 테스트는 코드의 유지 보수를 보다 쉽게 만들어주며, 신규 테스트 케이스를 추가하거나 기존 테스트 케이스를 수정할 때도 매우 유용합니다.

 

단위 테스트는 소프트웨어 개발의 초기 단계에서 잠재적인 버그를 찾아내는 데 매우 유용합니다. 개발자가 새로운 기능을 추가하거나 기존 코드를 변경할 때마다 단위 테스트를 실행하여 변경 사항이 기존 코드를 깨뜨리지 않는지 확인할 수 있습니다. 이렇게 하면 문제가 발생하면 즉시 원인을 찾아 수정할 수 있으므로 디버깅 시간을 크게 줄일 수 있습니다.

 

단위 테스트를 잘 설계하면 코드의 품질을 개선하고 코드가 예상대로 작동하는지 확인하는 데 도움이 됩니다. 이는 소프트웨어의 안정성을 높이는 데 중요한 역할을 하는데, 단위 테스트가 실패하면 해당 코드 단위에 문제가 있다는 즉각적인 피드백을 받을 수 있기 때문입니다.

단위 테스트는 일반적으로 테스트 주도 개발(Test-Driven Development, TDD)의 일부로 수행됩니다. TDD는 테스트를 먼저 작성한 후 이 테스트를 통과하는 코드를 작성하는 방법론입니다. 이 방법론을 사용하면 설계를 개선하고 코드의 유지보수성을 높일 수 있으며, 코드의 품질을 보장하는 데 도움이 됩니다.

 

단위 테스트를 작성하려면 테스트할 코드 단위를 선택하고, 해당 코드 단위가 올바르게 작동하는지 확인하는 테스트 케이스를 작성해야 합니다. 테스트 케이스는 일반적으로 별도의 테스트 프레임워크를 사용하여 작성되며, 이 테스트 프레임워크는 테스트 실행, 결과 리포팅, 테스트 케이스 작성을 도와주는 다양한 도구를 제공합니다.

 

그러나 단위 테스트는 모든 종류의 버그를 찾아낼 수 있는 만능 해결책은 아닙니다. 일부 버그는 여러 코드 단위가 상호작용할 때만 발생하므로 통합 테스트나 E2E 테스트를 통해 찾아낼 수 있습니다. 따라서 단위 테스트는 통합 테스트, 시스템 테스트, 인수 테스트 등 다른 테스트 수준과 함께 사용하여 전체적인 테스트 전략을 구축해야 합니다.

3-4) Static (정적 테스트)

개발자가 코드를 작성하며 생기는 문법 및 타입에러 오류, 타입스크립트를 사용할 때 함수의 인자로 받는 파라미터의 타입 검사 부분이 정적 테스트 유형에 포함될 수 있습니다. 코드 리뷰, 코드 인스펙션, 정적 분석 도구의 사용 등 다양한 방법이 있습니다.

 

코드 리뷰

코드 리뷰는 다른 개발자가 작성한 코드를 검토하는 과정입니다. 이는 코드의 품질을 높이고 버그를 예방하는 데 도움이 됩니다. 코드 리뷰는 개발자 간의 소통을 촉진하며, 코드의 가독성과 유지 보수성을 높이는 데 중요한 역할을 합니다.

 

코드 인스펙션

코드 인스펙션은 코드 리뷰의 한 형태로, 특정 체크리스트를 기반으로 코드를 검토하는 방법입니다. 이 체크리스트는 특정 프로그래밍 언어나 프로젝트에 특화된 규칙을 포함할 수 있습니다.

 

정적 분석 도구

정적 분석 도구는 코드를 자동으로 분석하여 버그, 코드 스멜, 안티 패턴 등을 찾아내는 도구입니다. ESLint, TSLint, SonarQube 등 다양한 정적 분석 도구가 있습니다.

 

정적 테스트는 개발 초기 단계에서 버그를 찾아내고, 코드의 품질을 높이는 데 도움이 됩니다. 또한, 동적 테스트와 함께 사용하면 테스트의 효과를 최대화할 수 있습니다.

통합 테스트와 E2E 테스트 ?

통합 테스트는 컴포넌트를 렌더링 하고 테스트를 하는 개념이고, E2E 테스트는 페이지에 접근해서 테스트하는 개념입니다. 쉽게 말해, 코드를 활용해 UI를 그려 테스트하는 것은 통합 테스트이고, 실제로 사용자가 서비스를 사용하는 것처럼 URL에 접근하는 테스트가 E2E 테스트라고 볼 수 있습니다.

4) Project

4-1) Prerequisites

• next.js (v14)
• typescript
• jest

4-2) Init

• 타입스크립트로 초기화하기

$ npx create-next-app [프로젝트 이름] --typescript

$ npx create-next-app hey-jest --typescript

4-3) Install jest

npm install -D jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom
# or
yarn add -D jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom
# or
pnpm install -D jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom

 

라이브러리	설명
jest	JavaScript 테스팅 프레임워크로, 단위 테스트를 위해 주로 사용됩니다.
jest-environment-jsdom	Jest에서 DOM 환경을 제공해주는 라이브러리로, 브라우저에서 동작하는 JavaScript 코드를 테스트하는 데 사용됩니다.
@testing-library/react	React 컴포넌트를 테스트하는 데 사용되는 라이브러리로, 사용자의 관점에서 테스트를 작성하는 것을 목표로 합니다.
@testing-library/jest-dom	Jest와 함께 사용되며, DOM 요소를 더 쉽고 읽기 쉽게 테스트하는데 도움을 줍니다.

4-4) Install ts-node

타입스크립트를 사용한다면, ts-node를 설치해야 합니다

yarn add -D ts-node

4-5) set the config

// 🗂️ jest.config.ts

import type { Config } from 'jest';
import nextJest from 'next/jest.js';

const createJestConfig = nextJest({
  // Provide the path to your Next.js app to load next.config.js and .env files in your test environment
  dir: './',
});

// Add any custom config to be passed to Jest
const config: Config = {
  coverageProvider: 'v8',
  testEnvironment: 'jsdom',
  // Add more setup options before each test is run
  // setupFilesAfterEnv: ['<rootDir>/jest.setup.ts'],
};

// createJestConfig is exported this way to ensure that next/jest can load the Next.js config which is async
export default createJestConfig(config);

4-6) Add script on package.json

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    // 아래 두 항목을 추가하였습니다.
    "test": "jest",
    "test:watch": "jest --watch"
  }
}

4-7) Initialize the test jsdom environment

테스팅할 예시 페이지를 선언했습니다.

// 🗂️ src/app/test-jest/page

import Link from 'next/link';

export default function Home() {
  return (
    <div>
      <h1>Home</h1>
      <Link href='/about'>About</Link>
    </div>
  );
}

Basic test code

// 🗂️ __tests__/page.test.jsx

import '@testing-library/jest-dom';
import { render, screen } from '@testing-library/react';
import Page from '../src/app/test-jest/page';

describe('Page', () => {
  it('renders a heading', () => {
    render(<Page />);

    const heading = screen.getByRole('heading', { level: 1 });

    expect(heading).toBeInTheDocument();
  });
});

4-8) Summary

import '@testing-library/jest-dom';

 

이 줄은 @testing-library/jest-dom 라이브러리를 가져옵니다. 이 라이브러리는 Jest의 단언(assertion) 매처(matcher)에 DOM 요소를 테스트하기 위한 추가적인 매처들을 제공합니다. toBeInTheDocument 와 같은 매처들은 DOM 요소의 존재 여부나 상태를 단언하는데 도움이 됩니다.

import { render, screen } from '@testing-library/react';
import Page from '../src/app/test-jest/page';

 

@testing-library/react에는 쿼리와 함께 작동하는 헬퍼 메서드가 있습니다. 요소들이 작업에 대한 반응으로 나타나고 사라질 때, waitFor 또는 findBy 쿼리와 같은 Async API를 사용하여 DOM의 변경을 기다릴 수 있습니다. 특정 요소의 자식 요소만 찾으려면 within을 사용할 수 있습니다. 필요한 경우 재시도 시간제한이나 기본 testID 속성과 같은 몇 가지 옵션을 구성할 수도 있습니다.

또한 쿼리의 요소에 따라 구분을 지을 수 있습니다.

describe(name, fn)

Globals · Jest

Globals · Jest

여기서는 @testing-library/react에서 render 함수와 screen 객체를 가져옵니다. render 함수는 테스트를 위해 React 컴포넌트를 렌더링 하는 데 사용되고, screen 객체는 렌더링 된 컴포넌트를 조회하는 유틸리티를 제공합니다. 또한 테스트할 Page 컴포넌트를 가져옵니다.

describe('Page', () => {
	// given - DOM에 페이지 컴포넌트가 그려짐
	// when - DOM에 페이지 컴포넌트가 그려졌을 때
	// then - 체크해라
});

 

Jest의 describe 함수는 주로 BDD(Behavior Driven Development) 스타일의 테스트 작성 시 사용되며, 테스트 케이스들을 그룹화하여 관리할 수 있게 해주는 역할을 합니다. 그룹화된 테스트 케이스들은 각자가 독립적으로 실행되며, 이 그룹은 테스트 결과 출력 시에도 의미 있는 구조를 제공합니다.

 

describe 함수는 'Given-When-Then' 스타일로 이해할 수 있습니다.

Given - When - Then

상활	설명
Given	테스트의 전제 조건을 설정합니다. 테스트에 필요한 데이터를 생성하거나, 특정 상태를 만드는 등의 작업을 수행합니다.
When	테스트의 대상이 되는 동작을 실행합니다. 특정 함수를 호출하거나, 사용자 이벤트를 시뮬레이션하는 등의 작업을 수행합니다.
Then	테스트의 결과를 단언(assert)합니다. 특정 값이 예상대로 변경되었는지, 특정 함수가 호출되었는지 등을 검사합니다.

 

describe 함수를 사용하여, 여러 테스트 케이스들이 동일한 'Given' 조건을 공유하도록 만들 수 있습니다. 그리고 각각의 테스트 케이스는 'When'과 'Then' 부분을 별도로 정의합니다. 이렇게 함으로써, 비슷한 조건에서 다양한 동작과 결과를 테스트할 수 있습니다.

각 상황(조건) 별로 test 코드를 실행시켜, 동작을 보장하는 편이 좋습니다.

it('renders a heading', () => {
  render(<Page />);

  const heading = screen.getByRole('heading', { level: 1 });

  expect(heading).toBeInTheDocument();
});

it 함수는 Page 테스트 모음 안에 단일 테스트 케이스를 정의합니다. 'renders a heading'은 이 테스트 케이스에 대한 설명입니다.

테스트 케이스 내부에서:

1. render(<Page />)는 render 함수를 사용하여 Page 컴포넌트를 렌더링 합니다.
2. const heading = screen.getByRole('heading', { level: 1 });은 screen 객체의 getByRole 함수를 사용하여 렌더링 된 컴포넌트 내에서 최상위 레벨(<h1>)의 제목 요소를 찾습니다. 일치하는 요소가 없으면 테스트는 실패합니다.
3. expect(heading).toBeInTheDocument();는 heading 요소가 문서에 렌더링 되었는지 단언합니다. toBeInTheDocument는 @testing-library/jest-dom에서 제공하는 커스텀 매처입니다.

이 테스트 케이스는 Page 컴포넌트가 렌더링 될 때 <h1> 제목 요소가 렌더링 되는지 확인합니다. 단언이 통과하면 테스트 케이스는 성공한 것입니다.

 

@testing-library/react와 @testing-library/jest-dom은 React 컴포넌트를 사용자 중심적으로 테스트할 수 있게 해 줍니다. 이들은 구현 세부사항(컴포넌트 인스턴스나 CSS 선택자)보다는 접근성 속성(역할, 레이블, 텍스트 내용 등)을 기반으로 요소를 조회하도록 권장합니다. 이렇게 하면 리팩토링에 더 잘 견디고, 사용자가 애플리케이션과 상호작용하는 방식에 더 잘 맞춰진 테스트를 작성할 수 있습니다.

expect

Expect · Jest

Expect · Jest

메서드	설명
expect(value)	값에 대한 단언을 시작합니다. expect 함수는 value 인자를 받고, 이 값은 주로 테스트하려는 코드의 결과입니다.
expect(value).toBe(expected)	값이 expected와 정확히 같은지(===) 확인합니다.
expect(value).toEqual(expected)	객체나 배열 같은 복합 데이터 타입이 expected와 깊은 비교로 같은지 확인합니다.
expect(value).not	not을 사용하면 다음 단언을 부정합니다. 예를 들어 expect(value).not.toBe(expected)는 value가 expected와 같지 않아야 통과합니다.
expect(value).toBeTruthy()	값이 truthy한지 확인합니다.
expect(value).toBeFalsy()	값이 falsy한지 확인합니다.
expect(value).toBeNull()	값이 null인지 확인합니다.
expect(value).toBeUndefined()	값이 undefined인지 확인합니다.
expect(value).toBeDefined()	값이 defined인지 확인합니다.
expect(value).toMatch(regexpOrString)	값이 문자열이나 정규표현식과 일치하는지 확인합니다.
expect(value).toContain(item)	배열 또는 문자열 값이 특정 항목을 포함하는지 확인합니다.
expect(value).toHaveLength(length)	값의 길이가 특정 길이와 같은지 확인합니다.
expect(value).toHaveProperty(keyPath, value?)	객체가 특정 속성을 가지고 있는지 확인합니다.
expect(value).toBeInTheDocument()	값이 DOM 상에 존재하는지 확인합니다.

it 함수 대신 test 함수를 써도 되나요 ?

Jest에서 it과 test는 동일한 역할을 합니다. 테스트 케이스를 정의할 때 it과 test를 아래와 같이 서로 바꿔 사용할 수 있습니다.

javascriptCopy codedescribe('Page', () => {
  it('renders a heading', () => {
// 테스트 케이스 내용
  });

  test('renders a heading', () => {
// 테스트 케이스 내용
  });
});

 

it과 test는 정확히 동일한 기능을 가지고 있습니다. 단지 it이 더 자주 사용되는 경향이 있을 뿐입니다.

실제로 Jest 공식 문서에서도 it과 test를 아래와 같이 설명하고 있습니다.

 

it 또는 test를 사용하여 테스트 케이스를 정의할 수 있습니다. 관행적으로 it가 더 일반적이지만, 이 둘은 완전히 같은 기능을 합니다. 테스트 케이스를 더 잘 설명하는 것을 선택하세요.

 

대부분의 개발자들은 it을 선호하는 경향이 있지만, 개인 취향이나 팀 컨벤션에 따라 test를 사용해도 무방합니다. 코드의 일관성과 가독성을 위해서는 프로젝트 내에서 둘 중 하나를 일관되게 사용하는 것이 좋습니다.

Types of Queries

• 단일 요소
  • getBy...: 쿼리에 맞는 노드를 반환하며, 요소가 없거나 둘 이상 일치하면 설명이 포함된 오류를 발생시킵니다 (둘 이상일 경우 getAllBy를 사용해요 합니다).
  • queryBy...: 쿼리에 맞는 노드를 반환하며, 요소가 없으면 null을 반환합니다. 요소가 없음을 확인할 때 유용합니다. 둘 이상 일치하면 오류를 발생시킵니다(둘 이상일 때 queryAllBy를 사용해야 합니다).
  • findBy...: 주어진 쿼리에 맞는 요소를 찾으면 Promise를 반환합니다. 요소를 찾지 못하거나 둘 이상의 요소가 1000ms 기본 시간 초과 후에도 있으면 Promise가 거부됩니다. 둘 이상의 요소를 찾아야 한다면 findAllBy를 사용하세요.
• 복수 요소
  • getAllBy...: 쿼리에 맞는 모든 노드 배열을 반환하며, 요소가 없으면 오류를 발생시킵니다.
  • queryAllBy...: 쿼리에 맞는 모든 노드 배열을 반환하며, 요소가 없으면 빈 배열([])을 반환합니다.
  • findAllBy...: 주어진 쿼리에 맞는 요소가 있으면 Promise를 반환하며, 이는 요소 배열로 해결됩니다. 요소를 1000ms 기본 시간 초과 후에도 찾지 못하면 Promise가 거부됩니다.
  • findBy 메서드는 getBy* 쿼리와 waitFor의 조합입니다. 마지막 인수로 waitFor 옵션을 허용합니다(예: await screen.findByText('text', queryOptions, waitForOptions)).

Type of Query	0 Matches	1 Match	>1 Matches	Retry (Async/Await)
Single Element
getBy...	Throw error	Return element	Throw error	No
queryBy...	Return null	Return element	Throw error	No
findBy...	Throw error	Return element	Throw error	Yes
Multiple Elements
getAllBy...	Throw error	Return array	Return array	No
queryAllBy...	Return []	Return array	Return array	No
findAllBy...	Throw error	Return array	Return array	Yes

Priority (쿼리 셀렉을 위한 메서드)

1. Queries Accessible to Everyone(모두에게 접근 가능한 쿼리), 시각/마우스 사용자뿐만 아니라 보조 기술을 사용하는 사용자의 경험을 반영하는 쿼리입니다.
   1. getByRole: 접근성 트리에 노출된 모든 요소를 쿼리하는 데 사용할 수 있습니다. name 옵션을 사용하면 접근 가능한 이름으로 반환된 요소를 필터링할 수 있습니다. 대부분의 경우 이것이 가장 선호되는 옵션이어야 합니다.
      1. 대부분의 경우 name 옵션을 사용하여 다음과 같이 사용됩니다: getByRole('button', {name: /submit/i}).
   2. getByLabelText: 이 메서드는 폼 필드에 좋습니다. 웹 사이트 폼을 탐색할 때 사용자는 레이블 텍스트를 사용하여 요소를 찾습니다.
   3. getByText: 폼 외부에서는 텍스트 콘텐츠가 사용자가 요소를 찾는 주된 방법입니다. 이 메서드는 비대화형 요소(div, span, 단락 등)를 찾는 데 사용할 수 있습니다.
2. Semantic Queries(의미론적 쿼리), HTML5 및 ARIA 규격에 따른 선택기입니다. 이 속성과 상호작용하는 사용자 경험은 브라우저와 보조 기술에 따라 크게 다릅니다.
   1. getByAltText: 요소가 alt 텍스트를 지원하는 요소(img, area, input 및 사용자 지정 요소)라면 이 메서드를 사용하여 해당 요소를 찾을 수 있습니다.
   2. getByTitle: title 속성은 스크린리더에 의해 일관되게 읽히지 않으며 시각 사용자에게는 기본적으로 표시되지 않습니다.
3. 테스트 ID
   1. getByTestId: 사용자가 볼 수 없고(들을 수도 없고) 역할이나 텍스트로 일치시킬 수 없거나 의미가 없는 경우(예: 텍스트가 동적인 경우)에만 권장됩니다.

---

4-9) results

$ yarn jest

 

레퍼런스

[인턴일지] 프론트엔드 개발에서 테스트가 필요한가요?

[인턴일지] 프론트엔드 개발에서 테스트가 필요한가요?

[test] jest와 react testing library 공부

[test] jest와 react testing library 공부

Jest

Jest

Testing: Jest

Testing: Jest | Next.js

단위 테스트 리뷰

단위 테스트 리뷰

https://github.com/jasonkang14/react-basics

GitHub - jasonkang14/react-basics

0. 강의의 목적

0. 강의의 목적 | Notion

Testing | TanStack Query Docs

Testing | TanStack Query Docs