{"id":"Bgimsk","createdAt":"2024-10-21T00:00:00.000Z","updatedAt":"2025-12-11T14:51:21.950Z","title":"React Unit/E2E 테스트 자동화 w. Vite/Next","content":"/// message-box --icon=info\n이 글은 [Vite로 시작하는 React 프로젝트](/p/6iFzkB)를 기반으로 설명합니다.\n[Next.js 프로젝트](/p/pd8CoS)에서 테스트를 시작하는 방법도 포함합니다.\n///\n\nReact 프로젝트에서 테스트를 시작하는 기본적인 방법을 소개합니다. \nVitest와 Testing Library를 사용한 단위 테스트, MSW를 활용한 API 모킹, 그리고 Cypress를 이용한 E2E 테스트의 핵심 개념과 간단한 예제를 통해 테스트 작성 방법을 이해해 봅니다.\n\n## 단위 테스트\n\n단위 테스트(유닛 테스트, Unit Test)란 상태나 함수, 모듈, 컴포넌트 등의 정의된 최소 단위들이 독립적으로 정상 동작하는지 확인하는 것을 말합니다.\n이를 통해 프로그램 전체의 신뢰도를 향상하고 코드 리팩토링(Code Refactoring)의 부담을 줄일 수 있습니다.\n\n- 정의된 최소 단위의 코드를 독립적으로 테스트합니다.\n- 외부 의존성을 최소화하고 모의해서(Mocking) 테스트합니다.\n- 빠르게 실행되며, 쉽게 자동화할 수 있습니다.\n- 코드 변경 시 즉각적인 피드백을 제공합니다.\n- 일반적으로 개발자가 직접 작성하고 관리합니다.\n\n### 단위 테스트 이점\n\n- 개발 초기에 문제점을 발견하여 수정 비용을 절감합니다.\n- 변경사항의 영향을 즉시 확인할 수 있어 안정적인 개발이 가능합니다.\n- 테스트 작성 과정에서 코드 구조와 설계가 자연스럽게 개선됩니다.(테스트하기 쉬운 코드는 대체로 잘 설계된 코드)\n- 기능 변경이나 코드 개선 시 예상치 못한 부작용을 방지합니다.(모든 테스트 통과는 기존 기능의 정상 작동을 보장)\n- 잘 작성된 단위 테스트는 실행 가능한 문서 역할을 합니다.(새로운 개발자가 시스템 동작을 빠르게 이해하는 데 도움)\n- 단기적으로는 테스트 작성에 시간이 소요되지만, 장기적으로 버그 수정과 유지보수 시간을 줄여 전체 개발 속도를 향상시킵니다.\n\n### Red-Green-Refactor\n\nRed-Green-Refactor는 테스트 주도 개발(TDD, Test-Driven Development)의 핵심 사이클로, 테스트를 3단계로 나눠 반복적으로 수행하는 방법을 말합니다.\n\n1. Red 단계: (아직 구현하지 않은 기능에 대한 )실패(Fail)하는 테스트를 작성합니다.\n2. Green 단계: 최소한의 코드를 통해 품질보다 구현에 집중해서 빠르게 성공(Pass)하는 테스트를 작성합니다.\n3. Refactor 단계: 가독성 향상, 중복 제거, 성능 최적화 등 코드를 개선합니다.\n\n다음 예제는 실패하지만, 어떤 기능을 만들어야 하는지 알 수 있습니다.\n\n/// message-box --icon=info\n`describe` 함수는 테스트 그룹을 정의하고, `test` 함수는 테스트 케이스를 정의합니다.\n`expect` 함수의 인수는 테스트 검증 대상이며, 체이닝으로 작성하는 메소드는 검증 방법을 정의합니다.\n`toBe` 메소드는 값이 같은지 검증합니다.\n///\n\n```tsx --path=/src/add.ts\nexport function add() {}\n```\n\n```tsx --path=/src/__tests__/add.test.ts\nimport { add } from '../add'\n\ndescribe('add', () => {\n test('1 더하기 2는 3이 돼야 합니다.', () => {\n expect(add(1, 2)).toBe(3)\n })\n})\n```\n\n![테스트 실패](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s1.JPG)\n\n해당 기능을 만들어 다시 테스트를 하면, 테스트를 통과합니다.\n\n```tsx --path=/src/add.ts\nexport function add(a: number, b: number) {\n return a + b\n}\n```\n\n![테스트 성공(통과)](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s2.JPG)\n\n좀 더 간결하게 표현하도록 화살표 함수로 변경하고, 함수의 반환 타입을 명시할 수도 있습니다.\n\n```tsx --path=/src/add.ts\nexport const add = (a: number, b: number): number => a + b\n```\n\n### Given-When-Then\n\nGiven-When-Then(혹은 Arrange-Act-Assert)은 테스트의 시나리오를 작성하는 방식으로, 테스트 코드를 준비 단계, 실행 단계 그리고 검증 단계로 나눠 코드의 가독성을 향상시키고 유지보수를 용이하게 합니다.\n\n다음 예제는 Given-When-Then 패턴을 사용하는 테스트 코드입니다.\n함수에 전달할 인수를 준비하고, 함수를 실행한 후, 결과를 검증합니다.\n\n```tsx --path=/src/__tests__/add.test.ts\nimport { add } from '../add'\n\ndescribe('add', () => {\n test('1 더하기 2는 3이 돼야 합니다.', () => {\n // Given(Arrange, 준비)\n const num1 = 1\n const num2 = 2\n\n // When(Act, 실행)\n const res = add(num1, num2)\n\n // Then(Assert, 검증)\n expect(res).toBe(3)\n })\n})\n```\n\n### 테스트 도구\n\n![Vitest](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s3.JPG)\n\n[Vitest](https://vitest.dev/)는 테스트 그룹(`describe`) 및 케이스(`test`), 검증, 테스트 러너(테스트 실행 및 결과 보고 등) 등을 제공하고, Vite 프로젝트와 완벽히 호환되는 테스트 프레임워크입니다.\n[Jest](https://jestjs.io/) 대비 10~20배 이상 빠르고 기본적으로 ESM을 지원합니다.\n그리고 [Jest API](https://jestjs.io/docs/api)를 대부분 사용할 수 있기 때문에, 이미 Jest 사용 경험이 있다면 보다 쉽게 이해하고 사용할 수 있습니다.\n\n![Testing Library](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s4.JPG)\n\n[Testing Library](https://testing-library.com/)는 사용자 중심의 테스트를 위한 간단하고 직관적인 테스트 유틸리티입니다.\n”테스트가 소프트웨어 사용 방식과 유사할수록 테스트의 신뢰도가 높아집니다.” 라는 개발자의 말처럼, 실제 사용자의 행동을 모방하는 테스트 작성을 장려합니다.\n\n### 테스트 환경 구성\n\n먼저 [Vite 프로젝트](/p/6iFzkB) 혹은 [Next.js 프로젝트](/p/pd8CoS) 구성 후, 다음과 같이 필요한 패키지를 설치합니다.\n\n```bash --caption=Vite.js 프로젝트\nnpm i -D vitest jsdom @testing-library/react @testing-library/dom @testing-library/user-event @testing-library/jest-dom @types/jest @vitest/coverage-v8\n```\n\n```bash --caption=Next.js 프로젝트\nnpm i -D vitest jsdom @testing-library/react @testing-library/dom @testing-library/user-event @testing-library/jest-dom @types/jest @vitejs/plugin-react vite-tsconfig-paths @vitest/coverage-v8\n```\n\n- __vitest__: Vite 기반의 빠르고 가벼운 유닛 테스트 프레임워크로, Jest와 유사한 API를 제공하면서도 10~20배 빠른 HMR(Hot Module Replacement)을 활용할 수 있습니다.\n- __jsdom__: 브라우저 환경을 Node.js에서 시뮬레이션하는 라이브러리로, 브라우저 없이도 DOM API를 활용해 테스트할 수 있습니다.\n- __@testing-library/react__: React 컴포넌트를 테스트하기 위한 가벼운 유틸리티 함수 모음입니다.\n- __@testing-library/dom__: DOM 노드를 테스트하기 위한 유틸리티 함수 모음으로, `@testing-library/react`의 기반이 되는 라이브러리입니다.\n- __@testing-library/user-event__: 실제 사용자 이벤트를 시뮬레이션하는 유틸리티로, 키보드 입력이나 마우스 클릭 등 사용자 상호작용을 테스트할 수 있습니다.\n- __@testing-library/jest-dom__: Jest의 expect 함수를 확장하여 DOM 관련 Matchers를 제공하며, `toBeInTheDocument()`, `toHaveTextContent()` 등의 DOM 특화 검증을 가능하게 합니다.\n- __@types/jest__: Vitest(Jest)의 전역 함수를 import 없이 사용할 때, 타입 오류를 방지하기 위한 타입 정의입니다.\n- __@vitejs/plugin-react__: Next.js 프로젝트에서 Vite 기반의 Vitest에서 JSX(TSX) 문법을 이해하고 React 컴포넌트를 처리할 수 있도록 합니다.\n- __vite-tsconfig-paths__: Next.js 프로젝트에서 TypeScript의 `tsconfig.json` 구성에 정의된 경로 별칭(Path Aliases)를 인식할 수 있도록 합니다.\n- __@vitest/coverage-v8__: Vitest 커버리지 테스트를 위한 패키지로, V8 엔진을 사용합니다.\n\n패키지 설치가 완료되면, 테스트 스크립트를 추가합니다.\n`\"test\"` 스크립트로 등록하면, 터미널에서 `npm t`(`npm test`, `npm run test`)로 실행할 수 있습니다.\n만약 E2E 테스트와 구분하려면, `:unit` 접미사를 추가하는 것도 좋습니다.\n\n/// message-box --icon=info\n`npm i -D @vitest/ui` 패키지를 설치하고 `\"vitest --ui\"` 스크립트를 사용하면 Vitest UI를 사용할 수 있습니다. \nVitest UI는 브라우저 기반으로 테스트 결과를 시각적으로 확인하고 코드를 수정하는 등 상호작용할 수 있습니다.\n![](https://vitest.dev/ui-1-dark.png \"--991x629\")\n///\n\n```json --path=/package.json\n{\n \"scripts\": {\n \"test\": \"vitest\",\n \"test:unit\": \"vitest\"\n }\n}\n```\n\n다음으로 Vitest 구성을 추가합니다.\n\nVite.js의 경우, `vite.config.ts` 구성 파일에 삼중 슬래시 지시자(Triple-slash directive, `///`)와 참조 태그(**``**)를 통해 Vitest의 타입 정의를 포함해야 합니다.\n`test.globals` 옵션은 테스트 파일의 전역 함수를 `import` 없이 사용할 수 있게 합니다.\n`test.environment` 옵션은 테스트 환경을 지정합니다.\n`test.setupFiles`는 테스트 전에 실행될 파일을 지정합니다.\n\n```ts --path=/vite.config.ts --line-active=1,8-17 --caption=Vite.js 프로젝트\n/// \nimport { defineConfig } from 'vite'\nimport react from '@vitejs/plugin-react-swc'\n\n// https://vitejs.dev/config/\nexport default defineConfig({\n plugins: [react()],\n test: {\n globals: true,\n environment: 'jsdom',\n setupFiles: ['vitest.setup.ts'],\n exclude: [\n './node_modules/**',\n './dist/**',\n './e2e/**',\n ]\n }\n})\n```\n\nNext.js의 경우, `vitest.config.ts` 파일을 생성하고 Vite 빌드 도구와 같은 환경을 제공합니다.\n\n```ts --path=/vitest.config.ts --caption=Next.js 프로젝트\nimport { defineConfig } from 'vitest/config'\nimport react from '@vitejs/plugin-react'\nimport tsconfigPaths from 'vite-tsconfig-paths'\n\nexport default defineConfig({\n plugins: [\n tsconfigPaths(), \n react()\n ],\n test: {\n globals: true,\n environment: 'jsdom',\n setupFiles: ['vitest.setup.ts'],\n exclude: [\n './node_modules/**',\n './.next/**',\n './e2e/**'\n ]\n }\n})\n```\n\n그리고 테스트 전에 실행될 내용을 `vitest.setup.ts` 파일에 추가합니다.\n\n`toBeInTheDocument()`, `toHaveTextContent()` 등의 DOM 특화 검증을 위해 `'@testing-library/jest-dom'` 모듈을 가져옵니다.\n그리고 `beforeEach` 함수로 각 테스트 케이스(`test` 함수) 실행 전에 수행할 작업을 정의합니다.(`test.globals` 옵션을 통해, `beforeEach` 함수를 전역으로 사용할 수 있습니다.)\n`cleanup` 함수는 React 컴포넌트를 정리하고 DOM을 초기화하는 역할을 합니다.\n이를 통해 테스트 간의 독립성을 보장하고 이전 테스트가 다음 테스트에게 영향을 미치지 않도록 합니다.\n\n```ts --path=/vitest.setup.ts\nimport '@testing-library/jest-dom'\nimport { cleanup } from '@testing-library/react'\n\nbeforeEach(() => {\n cleanup()\n})\n```\n\n### 첫 컴포넌트 테스트 코드 작성\n\n아직 내용은 없지만, `MovieList` 컴포넌트에서 영화 목록을 출력하려고 합니다.\n\n```tsx --path=/src/components/MovieList.tsx\nexport default function MovieList() {\n return <>\n}\n```\n\n처음으로 컴포넌트의 테스트 코드를 작성해 봅시다.\n`render` 함수는 컴포넌트를 렌더링하고, `screen` 객체로 렌더링된 컴포넌트를 확인할 수 있습니다.\n`getByText` 메소드는 특정 텍스트를 통해 요소를 찾아 반환합니다.\n`toBeInTheDocument` 메소드는 `expect`의 반환 요소가 문서에 존재하는지 검증합니다.\n\n/// message-box --icon=info\n`MovieList.test.tsx`와 같이 `.test` 혹은 `.spec` 이름이 포함된 파일은 테스트 파일로 인식됩니다.\n///\n\n```tsx --path=/src/__tests__/MovieList.test.tsx\nimport { render, screen } from '@testing-library/react'\nimport MovieList from '@/components/MovieList'\n\ndescribe('MovieList', () => {\n test('영화 목록을 출력해야 합니다.', async () => {\n render()\n expect(screen.getByText('Avengers: Infinity War')).toBeInTheDocument()\n expect(screen.getByText('Avengers: Endgame')).toBeInTheDocument()\n })\n})\n```\n\n간단한 모의(가짜) 데이터(Mock Data)로 영화 목록을 출력합니다.\n\n```tsx --path=/src/components/MovieList.tsx --line-active=13-16\nimport { useEffect, useState } from 'react'\n\nexport interface Movie {\n imdbID: string\n Title: string\n}\n\nexport default function MovieList() {\n const [movies, setMovies] = useState([])\n\n useEffect(() => {\n async function fetchMovies() {\n const movies = [\n { imdbID: '1', Title: 'Avengers: Infinity War' },\n { imdbID: '2', Title: 'Avengers: Endgame' }\n ]\n setMovies(movies)\n }\n fetchMovies()\n }, [])\n\n return (\n <>\n

Movie List!

{movie.Title}

\n \n )\n}\n```\n\n### 모의 작업\n\n`MovieList` 컴포넌트가 실제 영화 목록을 출력하도록 API를 사용하는 구조로 다음과 같이 `Movie` 타입과 `fetchMovies` 함수를 수정합니다.\n이제 실제 영화 목록을 잘 출력할 수 있습니다. \n하지만 이는 컴포넌트 내부의 함수를 외부에서 테스트하기 어려운 구조가 됩니다.\n\n```tsx --path=/src/components/MovieList.tsx --line-active=13-14\nimport { useEffect, useState } from 'react'\n\nexport interface Movie {\n imdbID: string\n Title: string\n}\n\nexport default function MovieList() {\n const [movies, setMovies] = useState([])\n\n useEffect(() => {\n async function fetchMovies() {\n const res = await fetch('https://omdbapi.com/?apikey=7035c60c&s=avengers')\n const { Search: movies } = await res.json()\n setMovies(movies)\n }\n fetchMovies()\n }, [])\n\n // ...\n}\n```\n\n따라서 더 나은 테스트성과 재사용성을 위해 데이터 패칭 함수를 다음과 같이 모듈화합니다.\n그러면 컴포넌트와 데이터 패치 로직을 분리하므로, 각각 독립적으로 테스트할 수 있습니다.\n\n```ts --path=/src/fetchers/movie.ts\nexport interface Movie {\n imdbID: string\n Title: string\n}\n\nexport async function fetchMovies(title: string): Promise {\n const res = await fetch(`https://omdbapi.com/?apikey=7035c60c&s=${title}`)\n const { Search } = await res.json()\n return Search\n}\n```\n\n```tsx --path=/src/components/MovieList.tsx --line-active=2-3,9\nimport { useEffect, useState } from 'react'\nimport { fetchMovies } from '@/fetchers/movie'\nimport type { Movie } from '@/fetchers/movie'\n\nexport default function MovieList() {\n const [movies, setMovies] = useState([])\n\n useEffect(() => {\n fetchMovies('avengers').then(setMovies)\n }, [])\n\n return (\n <>\n

Movie List!

\n {movies.map(movie => (\n

{movie.Title}

\n ))}\n \n )\n}\n```\n\n테스트 환경에서는 실제 구현한 함수를 그대로 사용하기 어려운 경우가 많습니다.\n예를 들어, 외부 API에 의존하는 함수는 네트워크 비용이 발생하고, 데이터베이스를 직접 조작한다면 테스트 실행 후 데이터베이스가 수정될 수 있습니다. \n또한, 복잡한 계산을 수행하는 함수는 실행 시간이 오래 걸려 테스트 속도를 저하시킬 수 있습니다.\n이러한 외부 요인들은 테스트 자체에 집중하기 어렵게 만듭니다.\n\n이런 상황에서 유용한 것이 바로 모의(Mock) 함수입니다.\n모의 함수는 말 그대로 '가짜' 함수로, 개발자가 원하는 대로 조작할 수 있습니다.\n네트워크 비용 없이 특정 결과를 즉시 반환하게 하거나, 의도적으로 에러를 발생시키거나, 함수가 몇 번 호출되었는지 감시하는 등 다양한 방식으로 활용할 수 있습니다.\n이를 통해 테스트에 방해되는 요인을 최소화하고, 테스트하고자 하는 로직에만 온전히 집중할 수 있게 됩니다.\n\n> [모의]: 실제의 것을 흉내 내어 그대로 해 봄.\n\n`MovieList` 컴포넌트가 `@/fetchers/movie` 모듈에서 가져오는 `fetchMovies` 함수는 네트워크 요청을 통해야 영화 목록을 가져올 수 있는데, 해당 모듈이 반환하는 `fetchMovies` 함수를 모의 함수로 대체해서 모의 데이터를 반환하도록 만듭니다.\n이렇게 모의 함수나 데이터를 만드는 것을 모의 작업(모킹, Mocking)이라 합니다.\n\n`vi` 객체는 Vitest에서 제공하는 다양한 [유틸리티 기능](https://vitest.dev/api/vi.html)을 가지고 있습니다.\n`vi.mock` 함수는 콜백의 반환 값으로 모듈을 대체합니다.\n`vi.fn` 함수는 모의 함수를 생성하고, `mockResolvedValue` 메소드는 모의 함수의 비동기 반환 값을 지정합니다.\n\n그리고 `MovieList` 컴포넌트를 렌더링하면, `fetchMovies` 함수가 모의 함수로 대체되어 모의 데이터를 반환합니다.\n그리고 `waitFor` 함수를 사용해 비동기 작업을 기다리도록 처리합니다.\n\n```tsx --path=/src/__tests__/MovieList.test.tsx\nimport { vi } from 'vitest'\nimport { render, screen, waitFor } from '@testing-library/react'\nimport MovieList from '@/components/MovieList'\nimport { fetchMovies } from '@/fetchers/movie'\n\nvi.mock('@/components/fetchers/movie') // 모듈 모의 작업\nconst mockedFetchMovies = vi.mocked(fetchMovies) // 실제 모듈의 타입에 맞게 모의 모듈 반환\n\ndescribe('MovieList', () => {\n test('영화 정보를 출력해야 합니다.', async () => {\n // fetchMovies 함수 모의 작업\n mockedFetchMovies.mockResolvedValue([\n { imdbID: '1', Title: 'Avengers: Infinity War' },\n { imdbID: '2', Title: 'Avengers: Endgame' }\n ])\n render()\n await waitFor(() => {\n expect(screen.getByText('Avengers: Infinity War')).toBeInTheDocument()\n expect(screen.getByText('Avengers: Endgame')).toBeInTheDocument()\n })\n })\n})\n```\n\n#### Mock Service Worker(MSW)\n\n![MSW](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s6.JPG)\n\n네트워크 요청/응답에 대한 모의 작업(Mocking)이 많은 경우, 이를 좀 더 쉽게 처리할 수 있는 방법이 있습니다.\nMock Service Worker(MSW)는 API Mocking 라이브러리로, 네트워크 요청을 가로채거나 관찰할 수 있으며 모의 응답을 반환합니다.\nMSW를 사용하면 실제 API와 유사하게 테스트를 수행할 수 있어, 더욱 신뢰성 있는 테스트 결과를 얻을 수 있습니다.\n\n```bash\nnpm i -D msw\n```\n\n`http.get` 메소드는 첫 번째 인수로 전달된 URL을 가로채고, 두 번째 콜백의 반환 값으로 응답을 반환합니다.\n요청 종류(Request Method)에 따라서 `http.post`, `http.put`, `http.delete` 메소드 등을 사용할 수도 있습니다.\n`HttpResponse.json` 메소드는 응답 본문을 JSON 형식으로 반환합니다.\n\n```tsx --path=/src/__tests__/MovieList.test.tsx\nimport { render, screen, waitFor } from '@testing-library/react'\nimport { http, HttpResponse } from 'msw'\nimport { setupServer } from 'msw/node'\nimport MovieList from '@/components/MovieList'\n\ndescribe('MovieList', () => {\n const server = setupServer() // 서버 생성\n beforeAll(() => server.listen()) // 모든 테스트 전에 서버 시작\n afterEach(() => server.resetHandlers()) // 각 테스트 후에 핸들러 재설정\n afterAll(() => server.close()) // 모든 테스트 후에 서버 종료\n\n test('영화 정보를 출력해야 합니다.', async () => {\n const response = {\n Response: 'True',\n Search: [\n { imdbID: '1', Title: 'Avengers: Infinity War' },\n { imdbID: '2', Title: 'Avengers: Endgame' }\n ],\n totalResults: '2'\n }\n server.use(\n http.get('https://omdbapi.com', () => {\n return HttpResponse.json(response)\n })\n )\n render()\n await waitFor(() => {\n // expect(screen.getByText('Avengers: Infinity War').toBeInTheDocument()\n // expect(screen.getByText('Avengers: Endgame')).toBeInTheDocument()\n expect(screen.getByText(response.Search[0].Title)).toBeInTheDocument()\n expect(screen.getByText(response.Search[1].Title)).toBeInTheDocument()\n })\n })\n})\n```\n\n추가로 앞서 모듈화한 `fetchMovies` 함수도 MSW를 사용해 다음과 같이 테스트할 수 있습니다.\n\n```tsx --path=/src/__tests__/movie.test.tsx --caption=모두 성공하는 테스트 케이스입니다.\nimport { http, HttpResponse } from 'msw'\nimport { setupServer } from 'msw/node'\nimport { fetchMovies } from '@/fetchers/movie'\n\ndescribe('fetchMovies', () => {\n const server = setupServer()\n beforeAll(() => server.listen())\n afterEach(() => server.resetHandlers())\n afterAll(() => server.close())\n\n test('영화를 성공적으로 가져옵니다.', async () => {\n const response = {\n Response: 'True',\n Search: [\n { imdbID: '1', Title: 'Avengers: Infinity War' },\n { imdbID: '2', Title: 'Avengers: Endgame' }\n ],\n totalResults: '2'\n }\n server.use(\n http.get('https://omdbapi.com', () => {\n return HttpResponse.json(response)\n })\n )\n const movies = await fetchMovies('avengers')\n expect(movies).toHaveLength(2)\n expect(movies[0]).toEqual(response.Search[0])\n expect(movies[1]).toEqual(response.Search[1])\n })\n\n test('영화를 가져오는데 실패합니다.', async () => {\n const response = {\n Error: 'Movie not found!',\n Response: 'False'\n }\n server.use(\n http.get('https://omdbapi.com', () => {\n return HttpResponse.json(response)\n })\n )\n const movies = await fetchMovies('존재하지 않는 영화!')\n expect(movies).toBeUndefined()\n })\n\n test('네트워크 오류가 발생합니다.', async () => {\n server.use(\n http.get('https://omdbapi.com', () => {\n return HttpResponse.error()\n })\n )\n await expect(fetchMovies('avengers')).rejects.toThrow()\n })\n})\n\n```\n\n### 사용자 이벤트\n\n키보드 입력이나 마우스 클릭 등의 사용자의 상호작용을 시뮬레이션할 수 있습니다.\n처음에 설치했던, `@testing-library/user-event` 라이브러리를 사용합니다.\n\n영화 제목을 입력하고 엔터키를 누르면, 영화 목록을 출력하도록 `MovieList` 컴포넌트를 수정합니다.\n\n```tsx --path=/src/components/MovieList.tsx --line-active=16-22\nimport { useEffect, useState } from 'react'\nimport { fetchMovies } from '@/fetchers/movie'\nimport type { Movie } from '@/fetchers/movie'\n\nexport default function MovieList() {\n const [movies, setMovies] = useState([])\n const [title, setTitle] = useState('')\n\n useEffect(() => {\n fetchMovies('avengers').then(setMovies)\n }, [])\n\n return (\n <>\n

Movie List!

\n setTitle(e.target.value)}\n onKeyDown={e => e.key === 'Enter' && fetchMovies(title).then(setMovies)}\n />\n

{movie.Title}

\n \n )\n}\n```\n\n`userEvent.setup` 함수는 사용자 이벤트를 시뮬레이션할 수 있는 객체를 반환합니다.\n`user` 객체에서는 `click`, `dblClick`, `keyboard`, `type` 등의 여러 상호작용 메소드를 사용할 수 있습니다.\n예를 들어, `type` 메소드는 텍스트 입력을 시뮬레이션합니다.\n`type` 메소드의 첫 번째 인수로 텍스트를 입력할 요소를 전달하고, 두 번째 인수로 입력할 텍스트를 전달합니다.\n입력할 텍스트에서 `{키이름}`을 사용하면, 키보드 입력을 시뮬레이션할 수 있습니다.\n\n다음 예제에는 `영화 제목을 입력하세요!` 플레이스홀더가 있는 입력 요소에 텍스트를 입력하고, 엔터키를 누르는 것을 시뮬레이션합니다.\n\n```tsx --path=/src/__tests__/MovieList.test.tsx --line-active=2,36-37\nimport { render, screen, waitFor } from '@testing-library/react'\nimport userEvent from '@testing-library/user-event'\nimport { http, HttpResponse } from 'msw'\nimport { setupServer } from 'msw/node'\nimport MovieList from '@/components/MovieList'\n\ndescribe('MovieList', () => {\n const server = setupServer() // 서버 생성\n beforeAll(() => server.listen()) // 모든 테스트 전에 서버 시작\n afterEach(() => server.resetHandlers()) // 각 테스트 후에 핸들러 재설정\n afterAll(() => server.close()) // 모든 테스트 후에 서버 종료\n\n test('영화 정보를 출력해야 합니다.', async () => {\n //...\n })\n\n test('영화 제목을 입력하고 엔터키를 누르면, 영화 목록을 출력합니다.', async () => {\n const user = userEvent.setup()\n const response = {\n Response: 'True',\n Search: [\n { imdbID: '1', Title: 'Batman Begins' },\n { imdbID: '2', Title: 'The Batman' }\n ],\n totalResults: '2'\n }\n let requestUrl = ''\n server.use(\n http.get('https://omdbapi.com/', ({ request }) => {\n requestUrl = request.url\n return HttpResponse.json(response)\n })\n )\n render()\n const searchInput = screen.getByPlaceholderText('영화 제목을 입력하세요!')\n await user.type(searchInput, 'batman{Enter}')\n const url = new URL(requestUrl)\n expect(url.searchParams.get('s')).toBe('batman')\n })\n})\n```\n\n### 커버리지\n\n커버리지(Coverage)는 테스트의 적용 범위를 말합니다.\n커버리지 확인을 통해서 테스트가 프로젝트에서 얼만큼 적용되었는지 확인할 수 있습니다.\n\n커버리지 확인을 위해서 다음과 같이 패키지를 설치합니다.\n\n```bash\nnpm i -D @vitest/coverage-v8\n```\n\n패키지 설치가 완료되면, 커버리지 확인용 스크립트를 추가합니다.\n\n```json --path=package.json --line-active=4\n{\n \"scripts\": {\n \"test:unit\": \"vitest\",\n \"test:unit:coverage\": \"vitest --coverage\"\n }\n}\n```\n\n다음과 같이 스크립트를 실행하면 커버리지 결과를 확인할 수 있습니다.\n앞서 `/src/components/MovieList.tsx` 파일과 `/src/fetchers/movie.ts` 파일의 테스트 코드를 작성했기 때문에 해당 파일들의 커버리지가 모두 100%로 표시되었습니다.\n커버리지가 높으면 테스트가 적용된 범위가 넓고 그만큼 프로젝트의 신뢰성이 높아지는 것을 의미합니다. \n하지만 커버리지가 높다고 해서 반드시 모든 면에서 좋은 것은 아닙니다. \n잘못된 테스트 코드가 얼마든지 있을 수 있기 때문에, 테스트의 질과 효율성, 그리고 테스트 코드 작성에 드는 시간 등의 기회비용도 함께 고려해야 합니다.\n\n```bash\nnpm run test:unit:coverage\n```\n\n![커버리지 결과](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s5.JPG)\n\n커버리지 결과표의 각 항목의 의미는 다음과 같습니다.\n\n| 항목 | 설명 |\n|---|---|\n| Stmts(Statements) | 단순히 각 구문의 실행을 확인 |\n| Branch | 조건문(If, Switch)의 각 분기 실행(가능한 모든 결과)을 확인 |\n| Funcs(Functions) | 각 함수 호출을 확인 |\n| Lines | 각 코드 라인의 실행을 확인 |\n| Uncovered Line | 테스트를 통해 실행되지 않은 코드 라인을 표시 |\n\n테스트 대상이 아닌 파일이 커버리지를 오염시키지 않도록, 다음과 같이 패턴을 작성해 제외할 수 있습니다.\n`test.exclude` 옵션은 커버리지의 제외 범위에 영향을 주지 않기 때문에, 커버리지에서 제외할 경로는 `test.coverage.exclude` 옵션으로 따로 지정해야 합니다.\n\n```ts --path=vite.config.ts --line-active=17-26\n/// \nimport { defineConfig } from 'vite'\nimport react from '@vitejs/plugin-react-swc'\n\n// https://vitejs.dev/config/\nexport default defineConfig({\n plugins: [react()],\n test: {\n globals: true,\n environment: 'jsdom',\n setupFiles: ['vitest.setup.ts'],\n exclude: [\n './node_modules/**',\n './dist/**',\n './e2e/**',\n ],\n coverage: {\n provider: 'v8',\n exclude: [\n '**/*.d.ts',\n '**/*.config.[jt]s',\n './src/routes/index.tsx',\n './src/components/Loader.tsx',\n './e2e/**'\n ]\n }\n }\n})\n```\n\n## E2E 테스트\n\nE2E 테스트는 애플리케이션의 전체 흐름을 처음부터 끝까지 테스트하는 방법을 말합니다. \n단위 테스트가 함수나 컴포넌트 같은 최소 단위의 동작을 검증하는 것에 집중하는 반면, E2E 테스트는 실제 사용자의 관점에서 애플리케이션의 전체적인 기능과 성능을 검증합니다.\nE2E 테스트의 목적은 애플리케이션이 의도한 대로 작동하는지 확인하고, 실제 사용 환경에서 발생할 수 있는 문제를 사전에 발견하는 것입니다.\n이를 통해 애플리케이션의 품질과 신뢰성을 높일 수 있습니다.\n\n- 실제 사용자가 애플리케이션을 사용하는 시나리오를 기반으로 테스트합니다.\n- 프론트엔드부터 백엔드, 데이터베이스 등 프로젝트의 모든 구성 요소를 포함해 테스트합니다.\n- 프로덕션 환경과 최대한 유사한 조건에서 테스트를 수행합니다.\n- 여러 구성 요소 간의 상호작용과 데이터 흐름을 확인합니다.\n- 반복적인 테스트를 자동화하여 효율성을 높일 수 있습니다.\n- 개발자가 작성하기도 하지만, QA 엔지니어나 테스트 담당자가 작성하는 경우도 많습니다.\n\n### E2E 테스트 이점\n\n- 사용자 관점에서 전체 시스템의 동작을 확인할 수 있습니다.\n- 여러 구성 요소 간의 상호작용에서 발생할 수 있는 문제를 찾아낼 수 있습니다.\n- 전체 비즈니스 흐름이 의도대로 작동하는지 확인할 수 있습니다.\n- 반복적인 테스트를 자동화하여 시간과 비용을 절약할 수 있습니다.\n- 전체 시스템의 안정성과 신뢰성을 높일 수 있습니다.\n- 다양한 브라우저, 디바이스, 운영 체제에서의 호환성을 확인할 수 있습니다.\n- 테스트 시나리오가 시스템의 기능 명세 역할을 할 수 있습니다.\n\n### Cypress\n\n[Cypress](https://www.cypress.io/)는 여러 브라우저 환경에서 테스트를 진행할 수 있는 프레임워크입니다.\nCypress의 주요 특징은 다음과 같습니다.\n\n- 테스트 코드 변경 시 자동으로 테스트를 다시 실행합니다.\n- 요소가 표시될 때까지 자동으로 기다립니다.\n- 테스트 실행 과정을 스냅샷과 비디오로 기록합니다.\n- 필요한 경우, 네트워크 요청을 모의할 수 있습니다.\n- 여러 브라우저에서 테스트를 실행할 수 있습니다.\n\n```bash\nnpm i -D cypress\n```\n\n`cypress open` 명령으로 GUI 환경에서 테스트를 진행할 수 있습니다.\n기본적인 테스트를 진행할 때 사용하는 명령입니다.\n\n`cypress run` 명령으로 Headless 모드로 테스트를 진행하면, 테스트 결과를 확인할 수 있는 브라우저 창이 열리지 않습니다. \n시각적 피드백이 필요 없는 상황에서 테스트 실행 속도와 효율성을 높이는 데 도움이 되며, 다음과 같은 상황에서 유용합니다.\n\n- CI/CD 파이프라인에서 자동화된 테스트를 실행할 때\n- 서버 환경에서 GUI가 없는 경우\n- 많은 수의 테스트를 빠르게 실행해야 할 때\n\n```json --path=package.json\n{\n \"scripts\": {\n \"cy:open\": \"cypress open\",\n \"cy:run\": \"cypress run\"\n }\n}\n```\n\n패키지 설치와 스크립트 등록이 끝났으면, `npm run cy:open` 명령으로 GUI 환경에서 테스트를 시작합니다.\n그러면 새로운 창이 열리면서 테스트 환경을 선택할 수 있습니다.\n__'E2E Testing'__ 버튼을 선택합니다.\n\n![Welcome to Cypress!](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s7.JPG)\n\n프로젝트에 자동으로 생성될 구성 파일을 목록으로 보여줍니다.\n하단의 __'Continue'__ 버튼을 선택합니다.\n\n![Configuration files](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s8.JPG)\n\n만약 구성 파일을 생성하는 과정에서 다음과 같은 에러가 발생하면, 프로젝트 루트 경로에 `cypress.config.ts` 파일의 확장자를 `.js`로 변경해 보세요.([관련 이슈](https://github.com/cypress-io/cypress/issues/23552)가 있습니다)\n그리고 화면에서 __'Try again'__ 버튼을 선택하거나 테스트를 종료하고 스크립트를 다시 실행해서 진행해 보세요.\n\n![ReferenceError](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s9.JPG)\n\n정상적으로 구성 파일이 생성되면, 다음과 같이 테스트할 브라우저를 선택할 수 있습니다.\n원하는 브라우저를 선택하고 __'Start E2E Testing in 브라우저'__ 버튼을 선택합니다.\n\n![Choose a browser](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s10.JPG)\n\n처음에는 테스트 파일이 없으니, __'Create new spec'__ 버튼을 선택해서 새로운 테스트 파일을 생성합니다.\n\n![Create your first spec](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s11.JPG)\n\n테스트 파일의 이름을 지정하고 __'Create spec'__ 버튼을 선택합니다.\n\n![Enter the path for your new spec](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s12.JPG)\n\n단순히 `https://example.cypress.io/` 사이트로 접속하는 최소한의 테스트 코드가 포함되며, 파일이 생성됩니다.\n__'Okay, run the spec'__ 버튼을 선택해서 마무리합니다.\n\n![Great! The spec was successfully added](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s13.JPG)\n\n기존에 작성한 `MovieList` 컴포넌트가 출력되는 페이지에서, 사용자가 접속하고 영화를 검색하는 시나리오를 테스트해 봅시다.\n페이지 접속 시 기본 영화 목록이 올바르게 표시되는지, 검색 기능이 정상적으로 작동하는지 확인하는 테스트 코드를 작성합니다.\n단위 테스트와는 달리 함수나 컴포넌트를 직접 가져와서 테스트하지 않고, 완성된 페이지에 접속해서 `cy.get` 함수로 요소를 찾고 화면의 내용을 확인하는 방식으로 테스트합니다.\n`cy.wait` 함수를 사용하면 특정 시간 동안 기다릴 수 있어, 비동기 작업을 처리할 때 유용합니다.\n\n```ts --path=/cypress/e2e/movie.cy.ts\ndescribe('영화 목록 페이지', () => {\n beforeEach(() => {\n cy.visit('http://localhost:5173/')\n })\n\n it('페이지 접속 시 기본 영화 목록이 표시되어야 함.', () => {\n cy.wait(1000) // 영화 목록을 가져오기까지 1초 동안 기다림!\n cy.get('h2').should('contain', 'Movie List!') //

요소의 텍스트가 'Movie List!'이어야 함!\n cy.get('ul li').should('have.length.gt', 0) //
요소가 1개 이상 있어야 함!\n cy.get('ul li').first().should('have.text', 'The Avengers') // 첫 번째
요소의 텍스트가 'The Avengers'이어야 함!\n })\n\n it('영화 제목 검색 시 해당 영화 목록이 표시되어야 함.', () => {\n cy.get('input[type=\"text\"]').type('batman{Enter}') // 텍스트 입력 후 엔터키!\n cy.wait(1000)\n cy.get('ul li').should('have.length.gt', 0)\n cy.get('ul li').first().should('contain', 'Batman Begins')\n })\n})\n```\n\n테스트 코드 작성이 끝나면, 화면에서 테스트를 진행할 파일을 선택합니다.\n\n![Select test file](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s14.JPG)\n\n테스트를 실행하면 우측에서 실제 접속한 페이지를 확인할 수 있습니다. \n이 페이지에서 테스트 코드가 실행되며, 각 단계마다 테스트의 동작을 시각적으로 확인할 수 있습니다. \n테스트가 진행됨에 따라 좌측 패널에는 각 테스트 케이스의 성공 또는 실패 여부가 실시간으로 표시됩니다. \n이를 통해 테스트의 진행 상황을 쉽게 파악하고, 문제가 발생한 경우 빠르게 대응할 수 있습니다.\n\n![Cypress Test](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s15.JPG)\n\n`cy.visit('http://localhost:5173/')`처럼 전체 URL을 사용할 수도 있지만, 하나의 사이트를 테스트한다면 `baseUrl` 속성을 사용해 기본 테스트 URL을 설정할 수 있습니다. \n이렇게 하면 테스트 코드가 많아지더라도 유지보수가 훨씬 쉬워집니다.\n또한, 개발 환경과 프로덕션 환경에서 URL을 쉽게 전환할 수 있어 편리합니다.\n\n`viewportWidth`와 `viewportHeight` 속성을 사용하면, 테스트 화면 크기를 설정할 수 있습니다.\n\n```ts --path=/cypress.config.ts --line-active=5-7\nimport { defineConfig } from 'cypress'\n\nexport default defineConfig({\n e2e: {\n baseUrl: 'http://localhost:5173',\n viewportWidth: 1280,\n viewportHeight: 720,\n setupNodeEvents(on, config) {\n // implement node event listeners here\n }\n }\n})\n```\n\n기본 URL을 설정했기 때문에, 이제 테스트 코드에서 전체 URL 대신 상대(하위) 경로만 사용하면 됩니다.\n\n```ts --path=/cypress/e2e/movie.cy.ts --line-active=3\ndescribe('영화 목록 페이지', () => {\n beforeEach(() => {\n cy.visit('/') // '/about', '/movies' 등\n })\n\n // ...\n})\n```\n\nCypress 구성에서 `video` 속성을 사용하면, Headless 모드로 테스트 실행 시 비디오 녹화를 자동으로 진행합니다.\n\n```ts --path=/cypress.config.ts --line-active=5\nimport { defineConfig } from 'cypress'\n\nexport default defineConfig({\n e2e: {\n video: true,\n // ...\n }\n})\n```\n\n```bash --caption=Run tests in headless mode\nnpm run cy:run\n```\n\n![Headless 모드의 테스트 비디오 녹화](https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/s16.JPG)\n\n지속적 통합(CI, Continuous Integration) 구성으로, GitHub의 `main` 브랜치에 푸시하거나 PR을 생성할 때 자동으로 테스트를 실행할 수 있습니다. \n이를 통해 코드 변경 사항이 프로젝트의 안정성에 미치는 영향을 즉시 확인할 수 있으며, 개발 과정에서의 오류를 조기에 발견하고 수정할 수 있습니다.\n\n```yml --path=/a.github/workflows/test.yml\n# GitHub Action 이름 지정!\nname: 테스트 실행!\n\n# 이벤트 지정!\non:\n push:\n branches: [ \"main\" ]\n pull_request:\n branches: [ \"main\" ]\n\n# 작업 지정!\njobs:\n test: # 작업 이름!\n runs-on: ubuntu-latest\n\n steps:\n - uses: actions/checkout@v4\n - name: Node.js 설정\n uses: actions/setup-node@v4\n with:\n node-version: '20'\n cache: 'npm'\n - name: 의존성 설치\n run: npm ci\n - name: 단위 테스트 실행\n run: npm run test:unit\n - name: Cypress 테스트 실행\n uses: cypress-io/github-action@v5\n with:\n start: npm run dev\n wait-on: 'http://localhost:5173'\n - name: Cypress 스크린샷 업로드\n uses: actions/upload-artifact@v3\n if: failure()\n with:\n name: cypress-screenshots\n path: cypress/screenshots\n - name: Cypress 비디오 업로드\n uses: actions/upload-artifact@v3\n if: failure()\n with:\n name: cypress-videos\n path: cypress/videos\n```\n\n### Playwright\n\n[Playwright](https://playwright.dev/)는 Microsoft에서 개발한 오픈소스 E2E 테스트 프레임워크입니다.\n실제 사용자의 관점에서 애플리케이션의 전체 흐름을 테스트할 수 있으며, Chromium, Firefox, WebKit 등 여러 브라우저 엔진을 지원합니다.\nPlaywright는 특히 크로스 브라우저 테스트와 복잡한 사용자 시나리오를 처리하는 데 강점을 가지며, Node.js 환경에서 동작합니다. \n또한, 자동화된 브라우저 테스트뿐만 아니라 모바일 뷰포트 에뮬레이션, 네트워크 모킹, 스크린샷 및 비디오 캡처 등 다양한 기능을 제공합니다.\n\n다음과 같이 설치합니다.\n\n```bash\nnpm create playwright@latest\n Initializing project in '.'\n ✔ Where to put your end-to-end tests? · tests\n ✔ Add a GitHub Actions workflow? (y/N) · false\n ✔ Install Playwright browsers (can be done manually via 'npx playwright install')? (Y/n) · true\n```\n\n설치가 완료되면, `/.gitignore` 파일에 버전 관리에서 무시할 Playwright 관련 경로가 추가되고 아래과 같이 테스트 폴더와 구성 파일이 생성됩니다.\n\n```plaintext --path=/.gitignore\n# Playwright\n/test-results/\n/playwright-report/\n/blob-report/\n/playwright/.cache/\n```\n\n```plaintext --caption=자동으로 추가되는 폴더 및 파일\n├─.github/\n│ └─workflows/\n│ └─playwright.yml\n├─tests/\n│ └─example.spec.ts\n├─tests-examples\n│ └─demo-todo-app.spec.ts\n├─playwright.config.ts\n```\n\nPlaywright의 구성 파일은 다음과 같습니다.\n\n```ts --path=/playwright.config.ts\nimport { defineConfig, devices } from '@playwright/test'\n\nexport default defineConfig({\n testDir: './tests', // 테스트 파일이 있는 디렉토리\n fullyParallel: true, // 모든 테스트를 병렬로 실행합니다\n forbidOnly: !!process.env.CI, // CI 환경에서만 테스트를 실행합니다\n retries: process.env.CI ? 2 : 0, // CI 환경에서 실패한 테스트를 최대 2번까지 재시도합니다\n workers: process.env.CI ? 1 : undefined, // CI 환경에서 1개의 프로세스로 실행합니다\n reporter: 'html', // 테스트 결과를 HTML 파일로 저장합니다\n // 모든 테스트에 공통으로 적용되는 설정\n use: {\n baseURL: 'http://localhost:5173', // 테스트 실행 시 사용할 기본 URL\n trace: 'on-first-retry', // 첫 번째 재시도에서만 트레이스를 수집합니다\n video: 'on-first-retry' // 첫 번째 재시도에서만 비디오를 수집합니다\n },\n // 테스트 실행 시 사용할 브라우저 설정\n projects: [\n {\n name: 'chromium',\n use: { ...devices['Desktop Chrome'] }\n },\n {\n name: 'firefox',\n use: { ...devices['Desktop Firefox'] }\n },\n {\n name: 'webkit',\n use: { ...devices['Desktop Safari'] }\n }\n ],\n // 테스트 실행 시 사용할 웹 서버 설정\n webServer: {\n command: 'npm run dev', // 웹 서버 실행 명령어\n url: 'http://localhost:5173', // 웹 서버 실행 시 사용할 URL\n reuseExistingServer: !process.env.CI, // CI 환경에서는 기존 서버를 재사용합니다\n timeout: 120 * 1000 // 웹 서버 실행 시간 제한\n }\n})\n```\n\nPlaywright는 지속적인 통합 구성이 자동으로 생성됩니다.\n브랜치 이름을 지정하거나 실패 시 메시지 전송 등 원하는 통합 방식으로 수정해서 사용하세요.\n\n```yml --path=/.github/workflows/playwright.yml\nname: Playwright Tests\non:\n push:\n branches: [main, master]\n pull_request:\n branches: [main, master]\njobs:\n test:\n timeout-minutes: 60\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v4\n - uses: actions/setup-node@v4\n with:\n node-version: lts/*\n - name: Install dependencies\n run: npm ci\n - name: Install Playwright Browsers\n run: npx playwright install --with-deps\n - name: Run Playwright tests\n run: npx playwright test\n - uses: actions/upload-artifact@v4\n if: ${{ !cancelled() }}\n with:\n name: playwright-report\n path: playwright-report/\n retention-days: 30\n```\n\n설치와 확인을 완료했으니, 로컬 테스트를 위한 스크립트를 추가합니다.\n\n```json --path=/package.json --line-active=5-7\n{\n \"scripts\": {\n \"test:unit\": \"vitest\",\n \"test:unit:coverage\": \"vitest run --coverage\",\n \"test:e2e\": \"playwright test\",\n \"test:e2e:ui\": \"playwright test --ui\",\n \"test:e2e:report\": \"playwright show-report\"\n }\n}\n```\n\n간단한 테스트를 작성합니다.\n페이지 접속 시 기본 영화 목록이 표시되고, 검색 기능이 정상적으로 작동하는지 확인합니다.\n\n- `test.describe`: 테스트 그룹을 정의합니다.\n- `test.beforeEach`: 각 테스트 전에 실행할 초기화 작업을 설정합니다.\n- `page.goto`: 지정된 URL로 이동합니다.\n- `page.locator`: 요소를 선택하며, CSS 셀렉터나 텍스트 기반으로 찾을 수 있습니다.\n- `expect`: 검증을 수행하며, Playwright는 요소가 나타날 때까지 자동으로 기다립니다.\n\n```ts --path=/tests/movie.test.ts\nimport { test, expect } from '@playwright/test'\n\ntest.describe('영화 목록 페이지', () => {\n test.beforeEach(async ({ page }) => {\n await page.goto('/') // baseURL을 기준으로 상대 경로 사용\n })\n\n test('페이지 접속 시 기본 영화 목록이 표시되어야 함', async ({ page }) => {\n await expect(page.locator('h2')).toHaveText('Movie List!')\n await expect(page.locator('div').filter({ hasText: 'The Avengers' })).toBeVisible()\n await expect(page.locator('div').count()).toBeGreaterThan(2) // 영화 항목 + 제목\n })\n\n test('영화 제목 검색 시 해당 영화 목록이 표시되어야 함', async ({ page }) => {\n const searchInput = page.getByPlaceholder('영화 제목을 입력하세요!')\n await searchInput.fill('batman')\n await searchInput.press('Enter')\n await expect(page.locator('div').filter({ hasText: 'Batman Begins' })).toBeVisible()\n await expect(page.locator('div').count()).toBeGreaterThan(2)\n });\n});\n```\n\n```bash --caption=Run tests in headless mode\nnpm run test:e2e\n```\n\n## 예제\n\n단위 테스트와 E2E 테스트가 적용된 간단한 React 프로젝트를 준비했습니다.\n\nhttps://github.com/ParkYoungWoong/lg_app1\n","isPublished":true,"isDeleted":false,"group":"React","tags":["React","Vitest","Testing Library"],"comments":0,"image":"https://somwpkzlplaovldnfahk.supabase.co/storage/v1/object/public/heropy.dev_posts/Bgimsk/main.jpg","description":"React 프로젝트에서 Vitest와 Testing Library를 사용한 단위 테스트, MSW를 활용한 API 모킹, 그리고 Cypress를 이용한 E2E 테스트 방법을 이해합니다.","postname":"react-testing-automation","video":[],"like":23,"embeddedAt":"2026-03-05T03:46:37.921Z","indexedAt":null}