FE 테스트 정리

0. 들어가며

기록한 FE 테스트에 관한 글을 바탕으로 프론트엔드에서 테스트를 어떻게 작성해야 하는지에 대해 정리

1. 단위 테스트

단일 함수의 결괏값 또는 단일 컴포넌트의 UI나 행위를 검증

1. 검증 대상

• 공통 컴포넌트
• 유틸 함수
• Hooks

2. 전략

• 로직없이 UI만 그리는 컴포넌트는 검증하지 않는다.(스토리북 사용)
• 로직이 간단하다면 상위 컴포넌트에서 통합 테스트로 함께 검증한다.

3. 한계

• 여러 모듈 조합에 대한 이슈를 검증하지 못한다.
• 기능 및 요구사항에 대한 검증이 불가능

2. 통합 테스트

2개 이상의 모듈 또는 컴포넌트의 로직을 검증

1. 검증 대상

• 상태나 데이터를 관리하는 컴포넌트
  • API와 연동되는 컴포넌트
  • 특정 상태를 기준으로 동작하는 컴포넌트

2. 전략

• 모킹을 최소화 하여 실제 환경과 유사하게 테스트
• 비즈니스 로직을 처리하는 API 호출 및 상태 관리 로직을 상위 컴포넌트에 응집시킨다.
• 여러 도메인의 기능이 조합된 로직은 분리하여 테스트한다.

3. 한계

• 전체 워크플로우를 검증하지 못하며, 시도하려면 모킹이 과도하게 필요하다.

3. 스냅샷 테스트

DOM 렌더링 결과 및 함수의 반환값을 직렬화하여 저장하고, 이후에도 동일한 결과가 나오는지 검증

1. 장점

• 의도하지 않은 변경을 빠르게 검출

2. 한계

• 의도하지 않은 스냅샷 업데이트 가능성
• CSS 스타일 변경에 대한 검증이 불가능
• TDD에 적합하지 않음

4. 시각적 회귀 테스트

렌더링 결과를 이미지로 저장하여 이후에도 동일한 결과가 나오는지 검증

1. 검증 대상

• UI만 렌더링 하는 컴포넌트
• 크로스 브라우징 또는 스타일 변경으로 UI가 자주 틀어지는 컴포넌트

2. 한계

• 테스트 실행 시간이 오래 걸림
• 테스트 실패 시 원인 파악이 어려움
• TDD에 적합하지 않음

5. E2E 테스트

실제 앱을 구동하여 시스템 전체를 검증

1. 검증 대상

• 시스템 전체에 대한 시나리오(BE ~ FE)

2. 전략

• 모킹을 최소화 하여 실제 환경과 유사하게 테스트
  • API 호출이 어렵거나, 실패 케이스, 외부 앱 사용과 같은 특별한 경우에만 모킹

3. 한계

• 실행 시간이 오래 걸림
• 외부 환경에 의존적이어서 테스트가 불안정함
• 테스트 실패 시 원인 파악이 어려움

6. 개발 프로세스에 맞는 테스트

1. 개발 진행 중

• 단위, 통합 테스트를 통해 로직 및 UI를 검증
• 스토리북을 통해 UI를 검증

2. 전반적인 개발 완료 후

• E2E 테스트를 통해 시스템 전체를 검증
• 시각적 회귀 테스트를 통해 UI 검증 자동화

7. 테스트의 최종 목적

사용자에게 안정적인 서비스를 제공하는 것