프론트엔드 테스트 생태계 구조

프론트엔드 테스트를 시작하려고 하면 Jest, Vitest, jsdom, Testing Library, MSW, Playwright 등 수많은 도구가 한꺼번에 쏟아집니다. 각 도구가 어떤 역할을 하고, 어떻게 조합되는지 전체 그림을 먼저 잡아두면 이후 학습과 도구 선택이 훨씬 수월해집니다.

왜 "생태계"로 이해해야 하는가

프론트엔드 테스트 도구는 하나만으로 모든 걸 해결하지 않습니다. test runner가 테스트를 실행하고, DOM 환경이 브라우저를 흉내내고, rendering 라이브러리가 component를 그리고, network mocking 도구가 API 응답을 대신합니다. 각 도구는 하나의 레이어를 담당하며, 이 레이어들을 조합해서 테스트 환경을 구성합니다.

테스트 도구의 레이어별 역할

Test Runner

test runner는 테스트 파일을 찾아 실행하고, 결과를 보고하는 최상위 레이어입니다. test(), expect(), mock 함수(vi.fn() / jest.fn()) 같은 core API를 제공합니다.

Jest는 Meta가 만든 테스트 프레임워크로, Node 환경에서 실행되며 CRA(Create React App)에 기본 내장되어 있습니다. Vitest는 Vite 기반 테스트 프레임워크로, Jest API와 거의 호환됩니다. ESM을 native로 지원하며, Vite 프로젝트에서 Jest를 대체하는 표준 선택지가 되었습니다. Vitest는 Jest API를 거의 그대로 따르기 때문에 migration 비용이 낮습니다.

DOM 환경

test runner는 Node에서 실행되기 때문에 document, window 같은 browser API가 존재하지 않습니다. DOM 환경 라이브러리는 이 browser API를 Node에서 시뮬레이션하는 역할을 합니다.

jsdom은 Node에서 browser DOM을 시뮬레이션하는 가장 널리 쓰이는 도구입니다. Jest와 Vitest 모두 기본값으로 사용하며, 호환성이 높은 대신 상대적으로 무겁습니다. happy-dom은 jsdom보다 빠른 경량 대안입니다. 대부분의 케이스에서 잘 동작하지만 일부 Web API를 지원하지 않습니다.

이 둘은 "가짜 브라우저"입니다. 빠르지만 실제 브라우저 동작을 100% 재현하지는 못합니다. 반면 Playwright 같은 도구를 통해 실제 브라우저를 띄우면 정확한 동작을 보장받을 수 있지만, 그만큼 느려집니다. 이 trade-off는 뒤에서 다시 다룹니다.

Component Rendering

DOM 환경 위에서 React component를 실제로 rendering하고, rendering 결과를 query하는 레이어입니다.

@testing-library/react는 jsdom이나 happy-dom 위에서 React component를 rendering합니다. render, screen, getByRole 같은 API를 통해 사용자 관점에서 component를 검증할 수 있습니다. vitest-browser-react는 실제 브라우저 위에서 React component를 rendering하며, Vitest Browser Mode 전용입니다.

Network Mocking

API 호출이 포함된 component를 테스트하려면 network 요청을 가로채서 원하는 응답을 돌려줘야 합니다.

MSW(Mock Service Worker)는 Service Worker(브라우저) 또는 Node interceptor를 사용해 HTTP 요청을 network 계층에서 가로챕니다. fetch든 axios든 HTTP client 구현과 무관하게 동작하기 때문에, 테스트가 구현 세부사항에 결합되지 않습니다. axios-mock-adapter는 axios 전용 mocking 도구입니다. HTTP client가 axios일 때 간단하게 쓸 수 있지만, 구현에 직접 결합된다는 한계가 있습니다.

현재 시점에서 MSW가 network mocking의 사실상 표준입니다. 브라우저와 Node 모두에서 동작하고, 실제 network 계층을 mocking하기 때문에 HTTP client 교체에도 테스트가 깨지지 않습니다.

조합 패턴

레이어를 이해했으면, 실제로 어떻게 조합하는지가 중요합니다. 프로젝트 상황에 따라 흔히 쓰이는 조합은 네 가지입니다.

가장 일반적인 단위/통합 테스트 조합은 Vitest + jsdom + @testing-library/react + MSW입니다. jsdom이 browser를 시뮬레이션하고, Testing Library가 component를 rendering하고, MSW가 API 응답을 mocking합니다. 대부분의 프로젝트에서 이 조합으로 시작합니다.

빠른 component 테스트가 목적이라면 Vitest + happy-dom + @testing-library/react 조합을 씁니다. jsdom 대신 happy-dom을 사용해 실행 속도를 높이되, network mocking이 필요 없는 순수 UI 테스트에 적합합니다.

실제 브라우저가 필요한 통합 테스트에는 Vitest Browser Mode + Playwright + vitest-browser-react 조합을 사용합니다. scroll, resize, 실제 CSS 계산 등 jsdom으로 재현할 수 없는 동작을 검증할 때 선택합니다.

E2E 테스트는 Playwright 또는 Cypress를 단독으로 사용합니다. 실제 서버를 띄우고, 브라우저에서 사용자 시나리오 전체를 검증합니다.

다음으로 알아볼 것들

이 글에서 다룬 생태계 구조를 바탕으로, 실제 테스트 작성에 들어가기 전에 몇 가지 개념을 추가로 이해해두면 좋습니다.

@testing-library의 query 우선순위(getByRole > getByLabelText > getByTestId)는 접근성 기반 테스트 철학을 이해하는 출발점입니다.