Skip to content

프론트엔드 테스트 전략

ukkodeveloper edited this page Aug 3, 2023 · 2 revisions

FE 테스트의 효용

팀 내부에서 프론트엔드 테스트 도구를 정하고 전략을 세우는 데 가장 중요하게 생각할 부분은 “테스트가 우리에게 도움이 되는가”이다. 만약 테스트 코드 작성하는 일이 불필요하게 리소스 낭비를 하고 있다고 느껴진다면 테스트를 할 필요가 없을 것이다. 따라서 코드의 종류를 세분화 한 다음, 테스트가 정말 필요한 것인지 확인하고 어떻게 테스트할 것인지 전략을 세웠다.

무엇을 테스트할 것인가?

✅ 유닛 테스트

다수의 도메인에서 사용될 도메인 함수의 경우 반드시 테스트를 해야 합니다. 전역적으로 영향을 미치기 때문에 안정성을 위해 내린 결정입니다. 추후 해당 도메인 로직을 수정해야할 때도 입력과 출력이 변하지 않은 상태에서 로직을 변경해야 합니다. 자동화된 테스트 코드는 해당 함수를 사용하는 곳에서 부작용이 일어나지 않도록 방어하는 역할을 합니다.

⏳ 공통 컴포넌트

공통 컴포넌트도 유틸 함수와 같이 전역적으로 영향을 미치는 코드입니다. 따라서 테스트의 필요성이 보이긴 했습니다.

하지만 저희는 공통 컴포넌트에 대한 테스트 코드 작성을 잠시 보류했습니다. 현재 초기 프로젝트 규모에서는 다양한 케이스에 대응할 수 있는 공통 컴포넌트를 만드는 것이 과도한 추상화라 여겼습니다. 즉, 공통 컴포넌트 역시 계속 변경될 여지가 많습니다. 따라서 현재 단계에서는 테스트 코드를 작성하는 것이 불필요하다고 느꼈습니다. 추후에 다양한 props를 받아 전역적으로 수월하게 사용할 수 있는 공통 컴포넌트 설계를 진행한다면, 그 때 테스트 코드를 작성하기로 결정했습니다.

🚫 컴포넌트

단일 컴포넌트의 경우 ui와 기능로 분류하여 테스트할 수 있습니다. 하지만 S-HOOK의 프론트엔드에서는 단일 컴포넌트에 대한 테스트를 하지 않기로 결정했습니다.

컴포넌트는 페이지 단위에서 여러 컴포넌트를 병합하는 과정에서 테스트 코드 자체를 변경해야할 일이 자주 일어났습니다. 가장 큰 이유는 상태를 관리하는 방법을 변경해야하는 경우가 생겼기 때문입니다. 예를 들어, 컴포넌트 내부에서 state를 관리하다가, props나 context API로 변경해야할 일이 많았습니다. 즉, 단일 컴포넌트 성격상 자주 변경이 일어납니다. 따라서 테스트 코드를 관리하는 것이 불필요한 리소스 낭비라고 판단했습니다.

이를 보안하기 위해 스토리북을 컴포넌트 단위로 작성합니다. 협업 시에 컴포넌트 단위로 쉽게 ui와 동작을 확인할 수 있도록 합니다.

⏳ 복합적인 컴포넌트 (integration)

복합적인 컴포넌트의 경우는 쉽게 변하지 않는 플로우가 있을 수 있습니다. 즉, 여러 컴포넌트끼리 상호작용함으로써 얻게되는 결과를 테스트 코드에 녹여낼 수 있을 것 같습니다. 이럴 경우 여러 컴포넌트끼리 상호 작용하는 과정을 리팩터링 하더라도 같은 결과를 강제할 수 있습니다. 하지만 변화에 취약하다는 팀원의 의견도 있었습니다.

복합적인 컴포넌트 테스트의 경우 아직 테스트 코드를 작성해 보지 않았고, 경험이 부족합니다. 그리고 아직 필요성도 느끼지 못한 것이 사실입니다. 따라서 프로젝트를 진행하는 과정에서 더 학습하고 경험한 뒤에 필수로 integration 테스트를 해야할 지에 대한 논의를 진행하기로 하였습니다.

⏳ E2E 테스트

E2E 테스트는 아직 고려하지 않기로 결정했습니다. 첫 번째 이유는 아직 프로젝트 규모가 작다는 것입니다. 페이지가 현재 3개, 추후 최대 5개 정도의 페이지로 서비스가 운용될 것으로 예상됩니다. Stroybook으로 컴포넌트 단위 QA를 하고, 페이지 단위는 직접 렌더링하여 QA하는 것으로 충분하다고 생각했습니다. 두 번째 이유는 Cypress 혹은 Storybook interaction에 대한 학습이 필요하다는 점입니다. 현재 E2E 테스트에 대한 필요성 대비 학습 리소스가 더 크다고 판단했습니다.

그럼에도 E2E 테스트는 서비스 제공 안전성에서 중요한 역할을 할 수 있다는 점을 인지하고 있습니다. 만약 배포 과정에서 예상치 못한 버그가 발생하거나, 예상치 못한 사용자 상호 작용이 발생할 경우 엄격한 E2E 테스트를 진행하기로 하였습니다.

어떻게 테스트할 것인가?

유닛 테스트

  • React 친화적인 Jest 도구를 사용하여 유닛 테스트를 합니다.
  • 성공 케이스, 실패 케이스, 엣지 케이스를 작성합니다.

컴포넌트

  • 컴포넌트 단위로 스토리북 작성을 하고 손수 테스트합니다.
Clone this wiki locally