프론트엔드 테스트 기본기와 Cypress

 

프론트엔드 개발에서 테스트 코드는 선택사항이 아닌 필수 요소가 되었습니다. 특히 React와 같은 컴포넌트 기반 라이브러리에서는 각 컴포넌트의 독립성과 재사용성을 보장하기 위해 체계적인 테스트 전략이 중요합니다. 이번 글에서는 React 테스트 코드 작성의 목적부터 실제 적용 방법까지 차근차근 살펴보겠습니다.

테스트 코드를 작성하는 이유

정확성과 신뢰성 확보

테스트 코드의 가장 기본적인 목적은 작성한 코드가 올바르게 동작하는지 확인하는 것입니다. React 컴포넌트는 다양한 props와 state 조합에 따라 다르게 렌더링되며, 사용자의 인터랙션에 따라 동적으로 변화합니다. 테스트 코드를 통해 이러한 모든 시나리오에서 컴포넌트가 예상대로 동작하는지 검증할 수 있습니다.

 

안전한 리팩토링 환경 제공

프로젝트가 성장하면서 코드 품질 개선, 성능 최적화, 새로운 패턴 적용 등의 리팩토링이 불가피합니다. 이때 테스트 코드는 변경사항이 기존 기능에 악영향을 미치지 않는다는 것을 보장하는 안전망 역할을 합니다.

일반적으로 프로젝트 초반에는 기능 구현에 집중하느라 테스트 코드 작성이 후순위로 밀리는 경우가 많습니다. 하지만 서비스가 안정화되고 리팩토링이 필요한 시점에는 반드시 테스트 코드를 먼저 작성한 후 리팩토링을 진행하는 것을 권장합니다. 이렇게 하면 기존 기능의 동작을 보장하면서도 안심하고 코드를 개선할 수 있습니다.

 

테스트 주도 개발(TDD)의 장점

테스트 주도 개발은 다음과 같은 사이클로 진행됩니다:

테스트 코드 작성 → 기능 구현 → 구현 코드 테스트 → 코드 수정 → 테스트 코드 작성

이 과정은 Jira 티켓을 활용한 작업 관리와 매우 유사한 패턴을 보입니다.

각 테스트 케이스를 하나의 독립적인 작업 단위로 간주할 수 있습니다. 예를 들어 "인풋이 활성화되면 underline이 바뀐다"라는 테스트는 그 자체로 하나의 구현해야 할 기능 요구사항입니다.

각 테스트 케이스의 통과 여부를 통해 해당 작업의 완료 상태를 즉시 확인할 수 있습니다. 이는 개발 진도를 객관적으로 측정할 수 있는 지표가 됩니다.

팀 단위 개발에서 각 팀원이 서로 다른 테스트 케이스를 맡아 병렬로 작업할 수 있습니다. 또한 각 기능별로 별도의 브랜치를 생성하여 작업하는 Git Flow와도 자연스럽게 연결됩니다.

다음은 실제 작업에서 활용할 수 있는 테스트 케이스 예시입니다:

 

describe("회원가입 페이지", () => {
  // 각 항목을 jira ticket으로 생각하고 작업할 수 있음
  // 브랜치 별로 테스트코드 작업 가능
  test("인풋이 활성화되면 underline의 컬러가 바뀐다.", async () => { });
  test("아이디가 중복이면 에러 메시지가 나타난다.", async () => { });
  test("비밀번호가 일치하지 않으면 에러 메세지가 나타난다.", async () => { });
  test("회원가입에 실패하면 에러메세지가 나타난다.", async () => { });
});

 

 

무엇을 테스트해야 하고, 무엇을 하지 말아야 할까?

테스트하지 않아도 되는 것들

레이아웃 관련 스타일링은 일반적으로 테스트 대상이 아닙니다. margin, padding과 같은 값들은 중요하지 않다는 의미가 아니라, 반응형 웹을 고려했을 때 다양한 화면 크기에서 동적으로 변하기 때문에 고정값을 테스트하는 것이 의미가 없기 때문입니다.

테스트하지 않는 것들의 예시:

• 구글 로그인 버튼과 이메일 로그인 안내문 사이의 거리
• 이메일 로그인 안내문과 이메일 레이블 사이의 거리
• 반응형을 고려한 마진 값들

 

반드시 테스트해야 하는 것들

비즈니스 로직과 사용자 인터랙션은 핵심 테스트 대상입니다. 사용자가 실제로 경험하는 기능들이 올바르게 동작하는지 확인해야 합니다.

테스트해야 하는 것들의 예시:

• 인풋 필드에 값이 정상적으로 입력되는지
• 버튼 클릭 이벤트가 올바르게 처리되는지
• 로그인 성공/실패 케이스가 적절히 처리되는지
• 에러 메시지가 올바른 조건에서 표시되는지

UI 디자인 관련 테스트는 별도로 Storybook을 활용하는 것을 권장합니다.

 

테스트의 종류와 적용 범위

React 애플리케이션에서는 세 가지 주요 테스트 유형을 활용할 수 있습니다.

유닛 테스트 (Unit Test)

가장 작은 단위의 테스트로, 개별 함수나 메서드가 예상대로 동작하는지 검증합니다.

로그인 기능의 유닛 테스트 예시:

• 이메일 인풋 필드가 정상적으로 입력을 받는지
• 비밀번호 인풋 필드가 정상적으로 입력을 받는지
• 로그인 버튼이 클릭 이벤트를 올바르게 처리하는지

통합 테스트 (Integration Test)

여러 모듈이나 컴포넌트가 함께 동작할 때 올바르게 작동하는지 검증합니다. 유닛 테스트의 결과물들이 하나로 묶여서 의도된 대로 동작하는지 확인하는 단계입니다.

로그인 기능의 통합 테스트 예시:

• 올바른 이메일과 비밀번호로 로그인이 성공하는지
• 잘못된 정보로 로그인 시도 시 적절한 에러 메시지가 표시되는지

E2E 테스트 (End-to-End Test)

실제 사용자가 웹사이트를 이용하는 것처럼 처음부터 끝까지 전체 플로우를 테스트하는 방법입니다. 자동화된 스크립트가 사용자의 행동을 시뮬레이션하여 실제 환경에서의 동작을 검증합니다.

로그인 기능의 E2E 테스트 예시:

• 로그인 페이지 접근 → 정보 입력 → 로그인 성공 → 메인 페이지 이동
• 로그인 페이지 접근 → 잘못된 정보 입력 → 에러 메시지 확인

마무리

테스트 코드는 단순히 버그를 찾는 도구가 아닙니다. 개발 과정에서의 설계 도구이자, 코드의 품질을 보장하는 안전망이며, 팀 협업을 원활하게 하는 커뮤니케이션 도구입니다.

처음에는 테스트 코드 작성이 개발 속도를 늦추는 것처럼 느껴질 수 있지만, 장기적으로는 더 안정적이고 유지보수하기 쉬운 코드베이스를 만드는 데 필수적인 투자입니다. 특히 React와 같이 컴포넌트의 재사용성이 중요한 환경에서는 각 컴포넌트의 독립성과 신뢰성을 보장하는 테스트 코드가 더욱 중요합니다.

특히 앞서 언급한 E2E 테스트의 경우, 실제 사용자 경험을 가장 가깝게 시뮬레이션할 수 있는 강력한 테스트 방법입니다. 이를 효과적으로 구현하기 위해서는 적절한 도구 선택이 중요한데, 그 중에서도 Cypress는 직관적인 문법과 강력한 기능으로 많은 개발자들에게 사랑받고 있는 E2E 테스트 프레임워크입니다.

다음 글에서는 Cypress의 기본 개념부터 실무에서 자주 사용하는 핵심 명령어들까지, 실제 프로젝트에 바로 적용할 수 있는 실용적인 내용들을 다뤄보겠습니다. 아래 링크 참고해주세요

https://ehdnsdlek.tistory.com/62

Cypress 기초 문법 및 설치 방법