---
type: knowledge
domain: frontend
status: active
last-reviewed: 2026-07-27
---

# 프론트엔드 테스트 실전

> 한 줄 정의
> 프론트 테스트는 "렌더링됐다"가 아니라 **"사용자가 한 행동에 화면이 맞게 반응했다"**를 검증한다. 자원 배분·플레이키·테스트 데이터 일반론은 [[테스트 전략 실전]] — 여기는 프론트 특유의 대상 선별과 도구 규율이다.

## 무엇을 테스트하나 — 로직 > 렌더링

| 우선순위 | 대상 | 방법 |
|---------|------|------|
| 1 | 화면 밖 로직 — 유틸·포맷터·검증 규칙·커스텀 훅 | 단위 테스트. 가장 싸고 가장 안 깨진다 |
| 2 | 사용자 행동 시나리오 — 입력→제출→결과, 필터→목록 갱신 | 컴포넌트 테스트 (렌더+상호작용) |
| 3 | 3상태 — 로딩·빈 값·에러 화면이 실제로 나오는가 | 컴포넌트 테스트. 성공 화면만 검증하는 것이 최다 공백 ([[프론트엔드 원리]] 3상태 원칙). 납품 검수는 [[03_화면·상태 명세]]의 상태 매트릭스 전체가 기준 |
| 후순위 | 정적 마크업 구조, 스타일 값, 프레임워크 동작 | 검증 가치 낮음 — 사용자에게 보이는 결과가 같다면 깨져도 버그가 아니다 |

- **스냅샷 남용 금지**: 전체 렌더 트리 스냅샷은 "무언가 바뀌었다"만 알려주고 무엇이 왜 문제인지 말하지 않는다 → 전원이 `-u`로 갱신을 습관화하는 순간 테스트가 아니라 의식이다. 스냅샷은 직렬화 결과가 곧 계약인 좁은 대상(에러 응답 변환 등)에만.

## 사용자 관점 쿼리 — role·label 우선

- 요소 선택은 사용자가 인지하는 방식 순서로: **role → label 텍스트 → 표시 텍스트**. `data-testid`는 최후 수단, CSS 클래스·DOM 구조 셀렉터는 금지 — 리팩토링만 해도 깨진다 ([[테스트 전략 실전]] "행동을 테스트하라").
- 부수 효과가 크다: role·label로 못 찾는 요소는 스크린리더도 못 찾는다 — **쿼리 규율이 곧 무료 접근성 검사**다 ([[접근성 실전]]).
- 상호작용은 실제 사용자 이벤트 시뮬레이션(클릭·타이핑·Tab)으로 — 내부 핸들러 직접 호출은 구현 결합이다.

## API 모킹 — 네트워크 경계에서 가짜로

- 모킹 지점은 **네트워크 경계**(MSW류 요청 인터셉트)가 기본값. fetch 함수·데이터 훅을 직접 mock하면 "훅을 mock한 훅 테스트"가 되어 아무것도 검증하지 않는다.
- 성공 응답만 모킹하지 않는다 — 5xx·타임아웃·빈 배열·필드 누락 응답이 3상태 테스트의 재료다.
- 핸들러 정의는 공유하되 **응답 데이터는 테스트가 자기 것을 선언** — 전역 목 데이터 하나를 전 테스트가 공유하면 수정 한 번에 무관한 테스트가 우수수 깨진다.
- 계약 어긋남(실서버와 목의 드리프트)은 모킹이 못 잡는다 — API 계약 문서를 정본으로 목을 갱신하는 규율이 필요하다 — 가능하면 OpenAPI 스키마에서 목·픽스처를 생성해 기계로 막는다 ([[03_프론트엔드 설계]] API 소비 계약).

## E2E — 핵심 여정만, 소수 정예

- 대상은 **비즈니스가 죽는 여정**만: 로그인→핵심 작업→저장/발송. 화면 전수 E2E는 느리고 플레이키해서 결국 무시된다 ([[테스트 전략 실전]] 역피라미드).
- 검증 세밀도는 낮게 — "여정이 끝까지 간다"를 확인하고, 세부 로직 검증은 아래 계층에 내린다.
- 대기는 조건 기반(요소 출현·응답 완료)으로, `sleep` 금지.
- 외주 관점: E2E 시나리오는 **검수 시나리오와 정렬**시킨다 — 검수일에 사람이 밟을 여정이 자동으로 매일 돌고 있으면 검수는 이벤트가 아니라 확인이 된다. 검수 기준은 착수 전 합의만 유효하다.

## 비주얼 회귀 — 비용을 알고 채택

| 항목 | 현실 |
|------|------|
| 강점 | 마크업 단언이 못 잡는 시각 붕괴(겹침·잘림·토큰 오적용)를 잡는 유일한 자동화 |
| 비용 | 렌더 환경(OS·폰트·안티앨리어싱) 차이로 오탐 상시 발생 — 기준 이미지 관리가 상근 업무가 된다 |
| 채택 기준 | 디자인 시스템 기본 컴포넌트·핵심 화면 소수에만. 전 화면 스크린샷 비교는 유지비가 신호를 잡아먹는다 |

- 도입한다면 렌더 환경 고정(동일 컨테이너)이 전제 조건이다.

## 안티패턴

- 커버리지 목표로 만든 "렌더만 해보는" 테스트 — 아무 미래의 실수도 잡지 않는다 ([[테스트 전략 실전]] 커버리지 굿하트).
- 구현 상세 단언 — 내부 상태 값·호출 횟수 검증은 리팩토링 탐지기다.
- E2E에서만 검증되는 로직 — 가장 비싼 계층에 가장 싼 검증을 두는 배분 실패.
- 플레이키를 재시도 옵션으로 덮기 — 처방은 [[테스트 전략 실전]] 플레이키 표.

## 관련 문서

- [[테스트 전략 실전]] — 자원 배분·플레이키·테스트 데이터 정본
- [[프론트엔드 원리]] — 3상태 원칙·상태 4분류
- [[접근성 실전]] — role·label 쿼리의 접근성 짝
- [[컴포넌트 설계 실전]] — props 렌더 가능성=테스트 가능성
- [[QA 원리]] — 자동화가 못 잡는 탐색적 테스트
- [[00_프론트엔드 허브]]