프론트엔드 테스트 전략

1. 왜 (테스트 목적)

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

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

모우다의 현재 테스트 범위: component 폴더안의 순수 컴포넌트의 UI를 StoryBook으로 테스트한다. ex)Button, TextArea, ***Card...

storybook 배포 사이트

• 훅 테스트 : input 데이터를 관리하는 훅
• validate: input 값에 대한 validate 테스트
• API 테스트: API를 연결하는 훅을 테스트 (현재 local 환경에서는 통과하나 cd환경인 gitAction에서는 테스트가 실패하여 추가 조치가 필요함)

3. 언제 (테스트 시점)

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

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

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

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

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

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