C.W.K.
Stream
Lesson 03 of 03 · published

Vitest, Playwright, Jest, Cypress — 언제 뭐 써?

~16 min · foundations, tool-selection, stack

Level 0테스트 호기심
0 XP0/32 lessons0/13 achievements
0/100 XP to next level100 XP to go0% complete
"테스트 도구 고르는 데 30분이면 충분해. 세 sprint 까지 갈 일 아냐."

2026년 일하는 스택

오늘 새 웹 프로젝트 시작하면 답은 짧아:

  • Vitest — unit, component, integration 테스트.
  • React Testing Library (RTL) — Vitest 위에 얹어서 컴포넌트 테스트.
  • MSW — 네트워크 mocking. Vitest 안에서도, Playwright 안에서도 동일하게 작동해.
  • Playwright — E2E 테스트.

이게 전부야. 패키지 네 개, test runner 두 개 (Vitest 와 Playwright 는 목적이 달라서 별개 프로세스로 돌아). 유일한 유효 스택은 아니지만 default 인 이유가 있어. 이 quest 나머지는 이걸 가정하고 가.

Jest 는?

Jest 는 여전히 훌륭한 소프트웨어야. 이미 Jest 로 돌아가는 큰 프로젝트 유지보수 중이면 Vitest 로 마이그레이션 비용이 가치 없을 수 있어 — Vitest API 는 대체로 Jest 호환이지만 config 의 미세한 차이와 edge case 가 발목 잡아. 근데 새 프로젝트라면 Vitest 가 세 축에서 이겨:

  • 속도: Vitest 는 Vite 의 transform 파이프라인을 재사용. 첫 테스트는 초 단위, 그 뒤로는 1초 미만.
  • ESM 네이티브: Jest 의 CommonJS 혈통은 현대 ESM 모듈을 어색하게 만들어. Vitest 는 ESM 우선.
  • 앱과 같은 toolchain: 이미 Vite 쓰고 있으면 (Next.js, Remix, SvelteKit, Astro 다 Vite 나 비슷한 도구 써), Vitest 가 너의 config 를 재사용.

Cypress 는?

Cypress 도 여전히 좋은 도구야. 현대 E2E ergonomic 의 많은 부분을 선도했어 — auto-wait, time-travel 디버깅, 개발 시간 UI. 근데 지난 3년간 Playwright 가 그 기능들을 따라잡거나 넘어섰고, cross-browser 실제 테스트 (Chromium + Firefox + WebKit) 까지 더했어. Cypress 는 Chromium 계열에서만 돌아가. 잘 돌아가는 Cypress suite 가 이미 있으면 유지해. 새로 고른다면 Playwright 가 답이야.

특별한 이유 없이 E2E 도구 섞지 마. Cypress 랑 Playwright 둘 다 굴리는 팀은 똑같은 것에 유지비, flake 조사 비용, 온보딩 비용을 두 번 내. 하나 골라서 commit 하고, 분기마다 재논쟁하지 마.

세 질문으로 결정하기

  1. 새 프로젝트, 기존 테스트 없음? Vitest + Playwright. 끝.
  2. 기존 Jest suite, 마이그레이션 고민 중? 비용 추정해. suite 가 작거나 이미 절반 다시 쓰고 있으면 마이그레이션. 거대하고 안정적이면 Jest 유지 — 둘 다 앞으로 몇 년은 지원돼.
  3. 기존 Cypress suite? Cross-browser 커버리지가 필요하거나 Cypress 특유의 마찰이 있을 때만 이전. 아니면 유지.

각 도구가 아닌 것

Vitest 는 브라우저가 아냐. Node 에서 DOM 에뮬레이터 (happy-dom 이나 jsdom) 와 함께 돌아. 실제 CSS, 실제 레이아웃, 실제 네트워크 — 그건 Playwright. Playwright 는 빠른 inner loop 가 아냐. 3초짜리 Playwright 테스트는 60밀리초짜리 Vitest 테스트보다 50배 느려. 두 도구는 speed/fidelity 축의 반대 끝에 의도적으로 살아. Vitest 로 레이아웃 테스트하려 하지 말고, Playwright 를 매 save 마다 돌리는 runner 로 쓰지 마.

Code

2026 default 테스트 스택 — package.json·json
{
  "devDependencies": {
    "vitest": "^4.1.5",
    "@vitest/coverage-v8": "^4.1.5",
    "@vitest/ui": "^4.1.5",
    "@testing-library/react": "^16.0.0",
    "@testing-library/user-event": "^14.5.0",
    "@testing-library/jest-dom": "^6.5.0",
    "happy-dom": "^15.0.0",
    "msw": "^2.6.0",
    "@playwright/test": "^1.48.0"
  }
}
결정 트리 — 세 질문, 네 답·text
Starting a new project?
  → Vitest + Playwright. Move on.

Have an existing Jest suite?
  → Is it large and stable? → Keep Jest. Don't migrate for fashion.
  → Is it small or already changing? → Vitest. The API is Jest-compatible.

Need component tests?
  → Vitest + React Testing Library + happy-dom. Not Playwright.

Need E2E?
  → Playwright. Skip Cypress for new projects.

Need network mocking?
  → MSW. It's the single answer for both Vitest and Playwright.

External links

Exercise

터미널 열어. 지금 프로젝트의 package.json 에서 test 관련 의존성 다 나열해 — 이름에 'test', 'jest', 'vitest', 'cypress', 'playwright', 'mocha', 'chai' 들어가는 거. 각각 위 스택에 분류해봐 (Vitest 동등? Playwright 동등? RTL? MSW? legacy 잔재?). 중복 있으면 (예: Jest 랑 Vitest 둘 다) 어느 쪽이 이기고 있는지 그리고 왜인지 적어.
Hint
흔한 놀라움: 프로젝트에 실제로 쓰는 unit runner 랑 아무도 안 돌리는데 deps 에 남아있는 legacy E2E 도구가 동시에 있어. 정상이야 — 어느 게 어느 건지 가려내는 게 실제 결정 작업이지.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.