Rosetta Page

Vitest Browser Mode vs Playwright

마
마루쉐

Front-End•2025.11.19

Epic Web Dev 블로그 포스트 번역
2025-11-12
원문: https://www.epicweb.dev/vitest-browser-mode-vs-playwright

이제 Browser Mode가 Vitest 4.0에서 안정화되었으니, 이에 대해 이야기할 시간입니다. 저는 약 1년 동안 개발자들에게 브라우저 유사 환경을 버리고 실제 브라우저에서 컴포넌트를 테스트하는 이점을 누리기 시작하도록 가르쳐왔습니다. 그리고 이에 대해 이야기할 때마다 같은 질문을 받습니다:
Vitest Browser Mode와 Playwright의 차이점은 무엇인가요?
정말 좋은 질문입니다. 표면적으로 이 도구들은 매우 유사합니다:
  • 둘 다 브라우저 자동화를 사용합니다;
  • 둘 다 유사한 API를 가지고 있습니다 (예: page);
하지만 이러한 표면적인 유사성은 이 도구들이 해결하도록 설계된 것과 내부적으로 어떻게 작동하는지를 자세히 살펴보면 끝납니다.
오늘은 Vitest Browser Mode와 Playwright의 차이점, 각각을 독특하게 만드는 것, 그리고 언제 각각을 사용해야 하는지를 살펴보겠습니다.

Purpose

Vitest Browser Mode는 브라우저에서 컴포넌트 수준의 테스팅을 제공합니다. 컴포넌트를 격리된 상태로 렌더링하고, 상호작용하며, 실제 페이지의 실제 브라우저에서 가지는 다양한 동작에 접근합니다. 이는 환경 무결성, 인체공학, 그리고 성능의 오랫동안 기다려온 결합으로, 마침내 JSDOM과 HappyDOM 같은 도구들을 구식으로 만듭니다. 더 이상 location, navigator, 또는 matchMedia를 모킹할 필요가 없습니다. 더 이상 취약한 테스트를 위해 테스트 설정과 싸울 필요가 없습니다. 저희의 컴포넌트는 사용자가 상호작용하는 곳에서 실행됩니다—실제 브라우저에서요.
반면 Playwright는 주로 end-to-end 테스팅 도구입니다. 컴포넌트를 실행하는 대신, Playwright 테스트의 실행 가능한 단위는 페이지입니다. 결과적으로, 저희는 다른 테스트를 작성합니다. 개별 컴포넌트가 아닌 애플리케이션 전체와 사용자가 이를 통해 수행할 수 있는 완전한 상호작용에 초점을 맞춘 테스트들입니다.
Playwright Component Testing은 Vitest Browser Mode에 훨씬 더 가깝습니다. 또한 컴포넌트 수준의 테스트에 초점을 맞추고, 실제 브라우저에서 코드를 실행하며, 관련된 이점을 제공합니다. 하지만 완전히 다르게 작동합니다.

Test environment

Browser Mode는 Vitest의 기능이며, Vitest는 Vite 위의 테스트 러너입니다.
Vite → Vitest → Browser Mode
Vitest 자체와 마찬가지로, Browser Mode를 즐기기 위해 Vite를 사용할 필요는 없습니다.
Vite 자체는 빌드 도구이며, Vitest는 이를 사용하여 테스트 스위트를 미니 앱으로 취급하고 브라우저에서 컴파일하고 제공합니다. 가장 중요한 구분은 다음과 같습니다: Vitest Browser Mode는 저희의 component.test.tsx를 브라우저에서 실행합니다. 이는 Vite를 사용하든 사용하지 않든 앱을 작성하는 것과 동일한 방식으로 작성할 수 있다는 의미입니다—JSX를 렌더링하고, CSS를 import하고, window와 document에 접근하는 등의 작업을 할 수 있습니다.
이는 또한 JSDOM에 익숙했다면, 테스트가 Node.js 프로세스에서 실행되는 브라우저 API polyfill의 혼합이었다면, Node.js 유틸리티가 테스트와 함께 제공되는 것에 대해 혼란스러워할 수 있다는 의미입니다. 저는 HTTP 서버, 파일 시스템 접근, 모든 node:* 내장 모듈, 또는 위의 것들에 의존하는 타사 도구에 대해 이야기하고 있습니다. 당연히 브라우저 테스트에서 이를 실행하면 오류가 발생합니다! Vitest는 이에 대한 답변을 Node.js 테스트 설정을 유지하는 형태로 제시합니다—놀랍게도—Node.js에서, 그리고 이를 Commands API를 통해 세분화하여 노출합니다. 이는 인체공학적인 솔루션입니다. Vitest는 브라우저 테스트를 실행하더라도 테스트 실행을 조율하기 위해 Node.js 서버를 이미 생성하기 때문입니다.
Playwright Component Tests는 Playwright 위에 구축되어 있으며, 그 아키텍처를 상속합니다. Playwright는 저희의 component.test.tsx를 Node.js에서 실행합니다, 메시지 채널에 의존하여 테스트와 브라우저가 통신하도록 합니다. 이 아키텍처는 전체 브라우저 자동화에는 훌륭하지만 컴포넌트 테스트에는 부족합니다. 테스트에서 컴포넌트가 렌더링되는 방식을 변경합니다.

Component rendering

Vitest Browser Mode는 완전히 프레임워크에 구애받지 않으며, 테스트된 컴포넌트를 애플리케이션이 렌더링하는 것과 동일한 방식으로 렌더링하도록 권장합니다. 예를 들어:
import { test, expect } from 'vitest'

import { page } from 'vitest/browser'

import { render } from 'react-dom'

//       ^^^^^^         ^^^^^^^^^

import { Greeting } from './greeting'

test('displays the greeting message', async () => {
  render(<Component />
  await element.expect(page.getByText('Hi, Kody!')).toBeVisible()
})
Vitest는 React와 Vue를 위한 것들과 같은 몇 가지 편의 패키지를 제공하며, 예를 들어 렌더링된 컴포넌트에 대한 직접 참조를 노출함으로써 렌더링 경험을 향상시키는 것을 목표로 합니다. 컴포넌트가 렌더링되는 방식에는 아무것도 변하지 않습니다 (React 컴포넌트를 렌더링하는 방식 참조). 저는 팀의 렌더링 접근 방식을 매우 좋아합니다. 왜냐하면 모든 프레임워크에 대해 저희 자신의 render() 함수를 구현하는 것을 매우 쉽게 만들기 때문입니다.
그 고유한 아키텍처로 인해, Playwright는 react-dom의 render()를 활용하여 React 컴포넌트를 테스트에서 직접 렌더링할 수 없습니다. 컴포넌트를 렌더링하는 장소 (Node.js 테스트)와 렌더링되어야 하는 장소 (브라우저 페이지)가 두 개의 별개 우주에 있기 때문입니다. 그래서 Playwright는 테스트에서 JSX를 직렬화하고 브라우저로 보내 충실하게 컴포넌트 트리를 재구성함으로써 이 두 우주 사이의 간격을 채웁니다.

Browser automation

Vitest Browser Mode는 자체 브라우저 자동화를 제공하지 않습니다. 대신, 브라우저 자동화 provider의 개념을 도입하고 지원되는 provider (현재 Playwright와 WebdriverIO) 중에서 선택하도록 합니다. 가장 좋은 부분은 해당 브라우저 자동화가 저희로부터 추상화되는 방식입니다:
// greeting.test.tsx
import { test, expect } from 'vitest'

import { page } from 'vitest/browser'

//       ^^^^

test('displays a greeting message', async () => {
  await element.expect(page.getByText('Hi, Kody!')).toBeVisible()
})
만약 저희가 이 컴포넌트 테스트가 어떤 브라우저 자동화를 사용하는지 묻는다면, 저희는 뭐라고 말할까요? 이것이 page이기 때문에 Playwright인가요? 이것이 WebdriverIO인가요? 이것이 다른 것인가요?
진실은, 중요하지 않다는 것입니다. Vitest는 저희의 테스트의 구현 세부사항을 page API 뒤에 숨깁니다. 이 API는 어떤 브라우저 자동화 provider를 사용하든 동일하게 유지됩니다. 저희는 하나 또는 다른 것을 선택할 수 있으며, 심지어 테스트 스위트 기준으로도 선택할 수 있으며, 저희의 테스트는 조금도 변하지 않습니다.
즉, Vitest가 노출하는 page API는 의도적으로 제한되어 있으며 Playwright의 동명 API의 모든 기능을 다루지 않습니다.
@playwright/test (테스트 프레임워크)는 브라우저 자동화를 위해 playwright (라이브러리)를 사용합니다. 이는 최고 수준이며, 이것이 저희가 end-to-end 테스트를 위해 Playwright를 사용하고 Vitest Browser Mode를 사용한 컴포넌트 테스트를 위해 브라우저 provider로 사용할 것을 강력히 권장하는 이유입니다.

Summary

다소 거친 그리고 주관적인 방식으로, 저는 이 비교를 몇 가지 짧은 문장으로 요약하려고 시도할 수 있습니다.
  • Vitest Browser Mode는 컴포넌트 테스트를 확장된 통합 테스트로 접근합니다;
  • Playwright는 컴포넌트 테스트를 제한된 end-to-end 테스트로 접근합니다.
결국, 컴포넌트 테스트는 설계상 통합 테스트이며, 따라서 저는 개인적으로 이 관점과 Vitest 팀의 특정 구현을 선호하는 것이 놀랍지 않습니다. Vitest는 뛰어난 테스팅 프레임워크이며, 저는 first-class Browser Mode API를 통해 브라우저 내 컴포넌트 테스트를 홍보하는 것을 보게 되어 기쁩니다.

Which should you use?

전반적으로 훌륭한 테스트에 대한 저의 개인적인 권장사항은 다음과 같습니다:
  • Node.js에서 단위 및 통합 테스트를 위해 Vitest를 사용하세요;
  • 실제 브라우저에서 컴포넌트를 테스트하기 위해 Vitest Browser Mode를 사용하세요;
  • 앱의 end-to-end 테스팅을 위해 Playwright (@playwright/test)를 사용하세요;
  • 일반적인 목적의 브라우저 자동화를 위해 Playwright (playwright)를 사용하세요.
0
5

댓글

?

아직 댓글이 없습니다.

첫 번째 댓글을 작성해보세요!