단위/컴포넌트 테스트로 잡기 어려운 로그인 → 목록 → 상세 같은 전체 흐름은 E2E(End-to-End)로 검증한다. 프론트에서 자주 쓰는 도구가 Cypress와 Playwright다.

🧪 E2E가 맞는 경우

• 라우팅, 쿠키, 실제 API(또는 staging)가 얽인 플로우
• "버튼이 보이는가"보다 "이 여정이 끝까지 가는가"
• 크로스 브라우저 확인이 필요할 때

단위 테스트로 충분히 커버되는 유틸, 순수 로직까지 E2E로 올리면 느리고 깨지기 쉬운 스위트가 된다.

🌲 Cypress

• 개발자 경험(GUI, time-travel)이 강한 편이다.
• 기본적으로 브라우저 안에서 테스트 코드를 돌리는 모델로 알려졌다.
• 프론트 중심 팀에서 도입 사례가 많다.

cy.visit('/login');
cy.get('[data-testid=email]').type('a@b.com');
cy.contains('로그인').click();
cy.url().should('include', '/dashboard');

🎭 Playwright

• Chromium, Firefox, WebKit을 한 API로 다루는 데 강점이 있다.
• 자동 대기, 트레이스, 병렬 실행, API mocking이 잘 갖춰져 있다.
• CI에서 headless 실행, 멀티 브라우저 매트릭스에 자주 쓰인다.

import { test, expect } from '@playwright/test';

test('login flow', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('이메일').fill('a@b.com');
  await page.getByRole('button', { name: '로그인' }).click();
  await expect(page).toHaveURL(/dashboard/);
});

⚖️ 비교

정답은 팀 스택과 CI 비용이다. "E2E를 얼마나 얇게 유지할 것인가"가 도구 선택보다 먼저다.

🛠️ 실무 팁

• E2E는 핵심 해피 패스 몇 개에 집중한다.
• data-testid
  • E2E 안정용으로 쓰기
  • 단위/RTL에서는 role, label을 우선
• flaky(간헐 실패)하면 아래를 먼저 본다.
  • 대기
  • 셀렉터
  • 환경(시드 데이터)
  • sleep으로 덮지 않기
• staging URL, 테스트 전용 계정이 있으면 로컬 mock만 믿을 때보다 신뢰가 올라간다.

🔺 피라미드와 위치

        E2E (적게)
      통합 / RTL
   단위 (Vitest/Jest)  ← 많이

아래가 많고 위로 갈수록 적을수록, 피드백은 빠르고 유지비는 줄어드는 편이다.

🔗 참고 자료

• Playwright Intro — Playwright 설치와 첫 테스트 작성을 안내한다.
• Cypress: Why Cypress — Cypress 도입 배경과 핵심 특징을 설명한다.
• Cypress Docs — Cypress 공식 문서 허브다.