[FE] 테스트 전략 수립

📘 테스트 우선순위

1. 핵심 기능에 대한 테스트 코드 작성 (jest, RTL)

   • 해당 코드가 동작하지 않으면 유저 스토리가 이뤄지지 않을 경우 무조건 작성

2. UI 테스트는 자식 컴포넌트가 없는 최소 단위의 컴포넌트만 작성 (storybook)

   • 컴포넌트 자체에 불필요한 스타일링이 들어가지 않았는지 확인하고, UI가 깨질 경우 컴포넌트 단위로 빠르게 처리 가능
   • props에 따라 UI가 바뀌는 경우 storybook 에서 확인할 수 있도록 스토리 구현 (핸들러 구현 X)
   • 해당 컴포넌트를 구현하지 않은 팀원이 storybook만 보고도 바로 이해할 수 있도록 작성

3. e2e 테스트 코드 작성 (cypress) - optional

   • 라운드 넘어가는 부분이나, 방만들고 대기 화면에 들어가는 부분을 직접 확인하면 너무 오래 걸릴 것이므로, e2e 테스트로 작성

4. 커스텀 훅 테스트 코드 작성 (jest, RTL) - optional

   • 만약 핵심 기능 코드와 연관된 커스텀 훅의 경우 우선적으로 작성

📘 어떤 도구를 사용해서 어떤 것을 테스트할 것인가?

✅ 유닛 테스트, 통합 테스트 (jest, RTL)

• 유저 스토리 를 기반으로 테스트를 작성
• 커스텀 훅 테스트 코드 작성
  • 모든 커스텀 훅 테스트 코드를 작성해야 하는가?
  • 선택이지만, 자신이 봤을 때 핵심 기능 코드와 연관된 커스텀 훅의 경우 작성
• 타이머가 다 지났을 때을 감지하여 잘 넘어가는지 테스트 코드 작성

✅ e2e 테스트 (cypress)

• 게임 화면 1라운드부터 5라운드 진행 후 게임 결과화면이 제대로 나오는지 테스트
  • API 데이터는 interceptor 로 mocking
• 방 만들기 버튼 클릭 후 닉네임 설정 후 대기방으로 이동하는지 테스트

📘 테스트 목적

사용자 관점에서 동작을 테스트하는 코드 와 복잡한 상황 위주로 테스트 코드를 작성할 예정입니다. 🤔

1. 코드 안정성

기능 구현이 완료된 후 리팩토링 과정을 거칠 예정입니다. 직접 동작을 테스트할 경우 놓치는 부분이 있고, 오류가 발생할 경우 기존 코드도 영향을 받아 여러번 테스트하여 리팩토링이 오래 걸린 문제가 있었습니다. 테스트 코드가 있으면 원래 동작하던 기능을 직접 테스트해보지 않아도 되므로, 마음 편하게 리팩토링할 수 있도록 테스트 코드를 작성할 예정입니다.

2. 피드백 사이클 축소

개발 서버를 열어서 간단하게 확인할 수 있는 테스트가 아니라, 바로 정상적인 동작인지 테스트할 수 없는 기능들이 있을 것으로 예상됩니다. 이럴 경우 테스트 코드를 통해 피드백 사이클을 줄일 수 있다고 생각하였습니다.

3. 스펙에 대한 문서화

나중에 코드를 봤을 때 문서를 찾아보지 않더라도, 해당 함수가 어떤 기능을 하는지 테스트 코드를 보고 빠르게 이해할 수 있을 것입니다. 그래서 기능 명세서에 작성했던 기능들에 대한 테스트 코드를 작성하려고 합니다.

📘 테스트 전략 수립

✅ 단위 테스트(jest, RTL)

💡 기능 명세에 작성된 기능에 대한 테스트 코드는 작성하자.

• 테스트 코드 작성하는 데에 시간이 많이 필요하기 때문에, 모든 기능에 대해 테스트 코드를 작성하는 것은 비효율적이라고 생각하였습니다. 하지만 객관적인 기준을 잡지 않으면 팀원마다 기준이 다르므로 테스트 코드를 점점 작성하지 않을 것 같았습니다.
• 나중에 코드를 읽거나 다른 사람의 코드를 읽을 때, 해당 로직이 어떻게 동작하는지 코드레벨로 모두 이해해야 합니다. 하지만 테스트 코드를 잘 작성해두면 따로 문서화를 하지 않더라도 테스트 코드만으로 동작을 예측할 수 있습니다. 따라서 기능 명세에 작성한 기능에 대해서는 테스트 코드가 필요하다고 생각하였습니다.

✅ UI 테스트(storybook)

💡 자식 컴포넌트가 없는 최소 단위의 컴포넌트만 storybook으로 만들자!

• 컴포넌트만 따로 분리해서 보기 편하고, 다른 사람이 만든 컴포넌트도 이해하기 쉬워 협업 관점에서 효율적이라고 생각하였습니다.
• 해커톤에서 분업하여 만든 컴포넌트를 페이지에 조합하여 사용할 때 혼란스러웠고, 이때 스토리북에서 바로 UI를 확인할 수 있었다면 혼란을 방지하고 명확하게 확인할 수 있었을 것이라는 생각이 들었습니다.
• 하지만, 모든 컴포넌트의 스토리를 만드는 것은 비효율적인 것 같다고 생각하여 공통 컴포넌트처럼 최소 단위의 컴포넌트만 스토리북으로 만들기로 하였습니다.

✅ e2e 테스트(cypress)

💡 라운드에 따라 넘어간 후 전체 결과를 보여주는 유저 플로우를 직접 테스트 하기에 어려움이 있어 필요하다고 생각하지만, 기능 구현과 단위 테스트 작성 후 고려

• e2e 테스트는 고려사항들도 많고, 사용자 시나리오를 생각해야 하므로 공수가 많이 든다고 생각하였습니다.
• 그래도 화면이 많이 넘어가고, 유저 플로우를 직접 테스트할 때 오래 걸리는 경우 e2e 테스트로 피드백 사이클을 줄일 수 있을 것입니다.
• 그래서 저희 서비스의 경우 라운드가 넘어가면서 전체 결과를 보여주는 기능이 있으므로, 이를 테스트할 때 사용할 예정입니다.