그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Testing
Testing

프론트엔드 E2E 테스트에 대해서 설명해주세요

실무4/5
설계4/5
인간3/5
기초2/5

면접관의 질문 의도

E2E 도구 이름만 아는지, 테스트 종류별 역할 분담과 flakiness 대응까지 잡는 사람인지를 가른다.

큐레이션 답변

학습 자료

프런트엔드 E2E 테스트는 실제 브라우저에서 사용자 흐름(로그인, 결제, 권한 경로)을 검증해 통합 지점의 회귀를 잡는 테스트다. 단위 테스트가 로직 정확성을 보장한다면, E2E는 라우팅·네트워크·상태 연동이 함께 동작하는지를 확인한다. 다만 느리고 flaky해지기 쉬워 모든 케이스를 E2E로 올리기보다 매출·보안·핵심 전환 시나리오를 우선 고정하는 게 효율적이다. 즉 테스트 피라미드의 _마지막 안전망_으로 운영해야 한다.

좋은 답변 구조

  1. 01E2E의 정의와 단위·통합 테스트라는 대안 축을 정리한다
  2. 02각 테스트의 이점(피드백 속도·실 장애 포착)과 한계(범위·flakiness·비용)를 균형 있게 설명한다
  3. 03매출 전환·보안·로그인 같은 _우선순위 기준_과 그 외는 단위/통합으로 빠지는 조건을 짚는다
  4. 04flakiness 대응(대기·네트워크 모킹·재시도)과 CI 비용을 고려한 결론으로 마무리한다

자주 실수하는 포인트

모든 케이스를 E2E로 덮으려 해 실행 시간이 폭증한다
flaky 테스트를 "가끔 실패하는 거니까" 식으로 방치한다
Cypress/Playwright 같은 도구 이름만 말하고 _무엇을_ 테스트할지 기준을 못 댄다
외부 API 호출을 그대로 둔 채 E2E를 깔아 환경 의존으로 만든다

실무 맥락

  • 결제·로그인·핵심 전환 흐름의 회귀를 막아야 하는 서비스
  • 마이크로프런트엔드/SSR 등 통합 지점이 많아 단위 테스트만으로는 안심이 안 되는 환경
  • flaky E2E가 CI를 흔들어 팀이 _재실행 버튼_에 의존하는 상황

본인 경험에 녹이는 힌트

결제 흐름 E2E를 깔아 회귀 사고를 막아본 경험이 있다면 "무엇을 E2E로 보호했는지" 기준이 그대로 답변 후크가 된다

flaky 테스트를 Playwright의 명시적 대기·네트워크 모킹으로 잡아본 경험이 있다면 운영성 이야기로 이어진다

단위/통합/E2E 비율을 팀에 정해본 적이 있다면 우선순위 판단 근거를 보여줄 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1어떤 시나리오를 E2E 우선 대상으로 선정하나요
Q2E2E 테스트의 flakiness는 어떻게 줄이나요
Q3유닛/통합/E2E의 비율은 어떤 기준으로 정하나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문