프론트엔드 테스트 전략

1. 왜 (테스트 목적)

1. 휴먼 에러를 없애기 위해 → 확실히 없앨 수 있어? → 걸러낼 순 있지. 100%는 아니라도, 90%는 없앨 수 있다. 근데 아예 테스트를 하지도 않으면 휴먼 에러를 아예 없앨 수 없다.
   • 심리적 안심 → 핵심 기능에 대한 테스트 코드를 만들면, 이게 정상 동작할 것이라 기대하기 때문에 안심을 할 수 있다.
2. 기능 명세서의 역할, 요구사항 만족 여부 확인

2. 무엇을 (테스트 대상)

대전제: 중요하다고 생각하는 것을 중점적으로 테스트한다.

→ 중요하다의 기준:우리가 추후 pr이나 코드를 봤을 때 직관적으로 크리티컬하다고 합의되는 것

→ 지금 우리가 명확한 기준을 세우기에는 부족하다. 점차 기준을 확립해나가자

1. 단위 테스트: 컴포넌트, 비즈니스 로직 모듈 하나를 테스트 하는 것
   • UI 테스트 → 개발을 하면서 할 수 있다. 이미 개발 단계에서 그걸 보면서 진행하기 때문에. (storybook으로 테스트)
     • components 폴더에 있는 컴포넌트
     • 단, 컴포넌트 단에서 데이터 패칭 등 불가피한 사이드 이펙트가 일어날 가능성을 배제할 수 없음 - 하지만 아직 불가피한 사이드 이펙트가 일어난 적은 없음
2. 통합 테스트: e2e 테스트도, 단위 테스트도 아닌 범위를 테스트하는 것
   • 비즈니스 로직 테스트
   • UI + 비즈니스 로직 통합 테스트
3. e2e 테스트: 페이지 단위 혹은 그 이상을 테스트 하는 것

3. 언제 (테스트 시점)

• PR에 프로덕션 코드와 함께 테스트 코드가 올라와야 한다.
• 데모데이와 같이 급박한 상황일 경우에는 테스트는 프로덕션 이후로 미룬다.

4. 어떻게 (테스트 도구)

• Storybook → 컴포넌트의 렌더링
• RTL → Hook, 컴포넌트의 동작
• (RTL을 사용하지 않는)jest → utility의 동작
• cypress → e2e 테스트

msw → 테스트할 때 실제 API를 사용하지 않기 위해 사용하는 도구

5. 어디서/누가 (테스트 하는 곳)

프론트엔드 팀원 모두 각자의 local, github action server