FE 테스트의 종류와 도구 총정리

프론트엔드 개발에서 테스트는 선택이 아닌 필수가 되고 있다. 어떤 종류의 테스트가 있고, 각각 어떤 상황에서 사용하면 좋을지 정리해보자.

🧩 1. Unit Test – "가장 작은 단위 테스트"

📌 목적

함수 하나, 컴포넌트 하나가 올바르게 작동하는지 확인

예시 코드

// 함수 테스트 (Jest)
function add(a, b) {
  return a + b;
}

test("add 함수", () => {
  expect(add(2, 3)).toBe(5);
});

🛠 도구 : Jest

🧠 적합한 상황

• 숫자 계산 함수
• 유틸리티 함수
• 상태 변경 함수 등

🧩 2. Integration Test – "여러 기능이 연결된 상태 테스트"

📌 목적

여러 컴포넌트/로직이 함께 잘 작동하는지 확인

예시 코드

// React 컴포넌트 테스트 (RTL + Jest)
test("추가 버튼을 누르면 할 일이 추가된다", async () => {
  render(<TodoApp />);
  await userEvent.type(screen.getByPlaceholderText("할 일"), "공부");
  await userEvent.click(screen.getByText("추가"));
  expect(screen.getByText("공부")).toBeInTheDocument();
});

🛠 도구: React Testing Library + Jest

🧠 적합한 상황

• 버튼 클릭 → 상태 변경 → DOM 반영 등 UI 흐름 테스트
• 컴포넌트 간 상호작용 테스트

🧩 3. E2E Test – "사용자처럼 전체 플로우 테스트"

📌 목적

브라우저에서 진짜 사용자가 하는 행동 그대로 재현

예시 코드

// Cypress 예제
cy.visit("/login");
cy.get("input[name='id']").type("psi7218");
cy.get("input[name='password']").type("1234");
cy.get("button[type='submit']").click();
cy.contains("환영합니다").should("be.visible");

🛠 도구: Cypress, Playwright

🧠 적합한 상황

• 로그인
• 결제
• 회원가입
• 전체 플로우 등 실제 사용자 시나리오

✅ 주요 테스트 도구 비교

도구	분류	테스트 실행 환경	주로 사용되는 테스트	주체
Jest	Test Runner (기반)	Node.js	Unit / Integration	함수, 로직
RTL (React Testing Library)	UI 테스트 도구	JSDOM	Unit / Integration	컴포넌트
Cypress	E2E 툴 (브라우저 기반)	브라우저	E2E	전체 UI & 서버
Playwright	E2E 툴 (MS 개발)	브라우저	E2E	전체 시스템

❓ Test Runner란?

작성된 테스트 코드를 실행해서 결과를 판단 후 출력하는 실행기
RTL의 경우, DOM(UI)탐색만 가능해서 단독으로 실행은 불가능 → RTL + Jest 로 하는 이유

🤸🏼‍♂️ 실행 환경의 차이

✅ JSDOM (Node.js 환경)

• 브라우저 없이 가짜로 DOM을 흉내냄
• 대부분의 UI는 테스트 가능
• ❌ 애니메이션, 미디어, 실제 폼 제출, 쿠키 등은 제한됨
• 📌 예: window.scrollTo(), canvas, video, ResizeObserver 등은 JSDOM에서는 테스트 자체가 안 되거나 불완전함

✅ 브라우저 환경 (Cypress/Playwright)

• 진짜 브라우저에서 테스트
• 실제 유저와 거의 동일한 환경 → 신뢰도 ↑
• 로컬스토리지, 세션스토리지, 브라우저 이벤트 모두 테스트 가능

⚡ 성능 차이

✅ Node + JSDOM

• 빠르고 가벼움
• 유닛/통합 테스트에 적합
• GitHub Actions에서 돌리기에도 부담 없음

❗ 브라우저 기반

• 무겁고 느림
• 모든 페이지를 렌더링하고 클릭/탭함
• E2E는 느릴 수밖에 없음

✅ 그래서 테스트는 섞어서 진행한다

• E2E는 실제 브라우저 환경에서 모든 기능을 검증하므로 정확하지만 느림
• Unit / Integration 테스트로 속도와 커버리지를 보완함
• 실무에서는 테스트 조합 전략을 세움

🛠 실무에서의 테스트 전략

일반 커밋 / PR 시

• ✅ Unit, Integration만 실행

master(main) 브랜치 머지 전

• ✅ Unit + Integration
• ✅ E2E 일부 시나리오 (Smoke Test)

정기 배포 또는 일정 기반

• ✅ 전체 E2E 테스트 실행
• → 대부분 GitHub Actions, GitLab CI, Jenkins 같은 CI/CD 툴에 연결

✅ 요약

테스트 유형	목적	예시 상황	사용하는 도구
Unit	작은 로직 단위 검증	함수, 계산기, 유틸	✅ Jest
Integration	컴포넌트 간 연결	버튼 클릭 → 결과 표시	✅ RTL + Jest
E2E	전체 사용 흐름 시뮬레이션	로그인 → 이동 → 로그아웃	✅ Cypress / Playwright

🔍 테스트코드 관련 면접 예상 질문

1. 테스트 코드를 왜 작성하셨나요?

   • 단순히 버그를 잡기 위해서인가요?
   • 코드 품질 관리 측면에서 어떤 가치를 느끼셨나요?

2. 개발하면서 테스트가 꼭 필요하다고 느꼈던 순간이 있었나요?

3. 테스트 코드 작성은 프로젝트 일정에 도움이 되었나요, 오히려 방해되었나요?

4. 컴포넌트를 테스트할 때 중요한 기준이 있으신가요?

   • 내부 상태 vs 외부 결과, 사용자 관점 등

5. TDD 해보셨나요?

   • 했다면 어떤 방식으로? (Red → Green → Refactor 경험 질문)

6. Cypress와 Playwright의 차이점을 알고 계신가요?

   • 선택 기준을 어떻게 세우시나요?

7. JSDOM 환경에서 안 되는 테스트는 어떤 게 있나요?

   • 실제 브라우저 환경이 필요한 사례를 설명할 수 있나요?

8. CI/CD 환경에서 테스트는 어떻게 구성하셨나요?

   • PR마다 Unit만 돌리나요? E2E는 언제 돌리나요?

9. E2E 테스트가 너무 느리다면 어떻게 개선하실 건가요?

10. 테스트가 깨졌는데, 실제로는 정상일 경우 어떻게 처리하나요?

    • False positive 대응 전략

🧠 후속 꼬리질문 흐름 예시

• "테스트 코드를 작성하신다고 했는데, 왜 작성하신 건가요?"
  • → "그럼 항상 테스트 코드를 작성하시나요? 어떤 기준으로 결정하나요?"
    • → "E2E 테스트도 작성하시나요? Cypress와 Playwright 중 어떤 걸 선호하시나요?"
      • → "JSDOM 환경과 실제 브라우저 환경의 차이를 설명해보세요."
        • → "CI/CD에서는 어떻게 테스트를 구성하셨나요?"

🔗 참고 링크

• React Testing Library 공식 문서
• Playwright 소개 블로그