E2E 테스트(엔드투엔드 테스트)

E2E 테스트(End-to-end test)는 사용자가 하는 방식 그대로 시스템을 실행하며, 모든 계층이 실제입니다. 브라우저, 프런트엔드, 백엔드 서비스, 데이터베이스, 큐, 그리고 가능하다면 서드파티 연동까지 포함합니다. 하위 레벨 테스트가 답할 수 없는 질문, 즉 “실제 여정에서 전체가 정말 함께 동작하는가?“에 답합니다. E2E 테스트는 가장 현실적인 신뢰를 주는 대신 비용이 가장 높기 때문에 테스트 피라미드의 맨 위에 위치합니다.

예시 (Playwright)

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

test('guest can buy a product', async ({ page }) => {
  await page.goto('/');
  await page.getByRole('searchbox', { name: 'Search' }).fill('desk lamp');
  await page.keyboard.press('Enter');
  await page.getByRole('link', { name: 'Desk Lamp' }).click();
  await page.getByRole('button', { name: 'Add to cart' }).click();
  await page.getByRole('link', { name: 'Checkout' }).click();
  await page.getByLabel('Email').fill('guest@example.com');
  await page.getByRole('button', { name: 'Place order' }).click();
  await expect(page.getByRole('heading', { name: 'Thank you for your order' })).toBeVisible();
});

테스트 하나가 검색, 카탈로그, 장바구니, 결제, 주문 서비스를 모두 거칩니다. 장바구니 서비스가 가격을 잘못 직렬화하면, 모든 서비스의 단위 테스트가 통과하더라도 이 테스트가 잡아냅니다.

E2E 테스트를 적게 유지하는 이유

• 느립니다. 단위 테스트가 밀리초 단위라면 E2E 테스트는 하나에 수 초에서 수 분이 걸립니다.
• 플래키해지기 쉽습니다. 움직이는 부분이 많을수록 타이밍 문제, 공유 데이터, 환경 불안정성이 늘어납니다.
• 진단이 어렵습니다. “결제 실패”는 십여 개 서비스 중 어디서든 생길 수 있습니다.
• 유지보수 비용이 큽니다. UI 변경이 많은 테스트에 파급됩니다.

따라서 E2E 테스트는 회원가입, 구매, 핵심 워크플로처럼 중요한 비즈니스 여정에만 쓰고, 변형(모든 검증 규칙, 모든 할인 유형)은 단위 테스트와 API 레벨에서 커버하세요.

신뢰할 수 있게 만드는 방법

• Playwright의 자동 대기와 웹 퍼스트 어설션, Selenium의 WebDriverWait 같은 조건 기반 대기를 쓰고, 고정 sleep은 절대 쓰지 마세요.
• UI를 클릭해서 데이터를 만들지 말고 setup 단계에서 API로 테스트 데이터를 생성하고, 각 테스트가 자기 데이터를 갖게 하세요.
• 레이아웃에 의존하는 XPath 대신 역할, 레이블, 테스트 ID 같은 안정적인 로케이터를 쓰세요.
• 페이지 오브젝트 등으로 코드를 구조화해서 UI 변경을 한 곳에서 고칠 수 있게 하세요.

“E2E”와 “시스템 테스트”는 의미가 겹칩니다. 시스템 테스트는 테스트 레벨을 가리키고, E2E는 모든 계층을 통과하는 테스트의 스타일을 가리킵니다.