개발자 김성빈
개발자 김성빈
AboutContact
자동화된 웹 프론트엔드 테스트 2 - How - 이론편

자동화된 웹 프론트엔드 테스트 2 - How - 이론편

Tags
Automated Test
Published
February 9, 2025
Author
Seongbin Kim
작성 중
작성 중
1. 웹 프론트엔드 테스트 자동화 방법의 종류2. 테스트 자동화의 대상 및 적절 테스트 종류3. 테스트 작성 방법3-1. 단위 테스트3-2. 컴포넌트 통합 테스트3-3. E2E 테스트 (Playwright)4. 다른 도구와 연동4-1. Storybook 활용4-2. Storycap, reg-cli, reg-suit 활용
 

1. 웹 프론트엔드 테스트 자동화 방법의 종류

종류
설명
예시
장점
단점
단위 테스트 (jest)
역할과 입출력이 명확한 코드를 jest로 실행.
순수 함수로 작성한 비즈니스 로직 함수 테스트
단독으로 테스트가 가능하므로, 테스트 코드의 길이와 실행 시간이 가장 짧음
프로덕션의 동작은 거의 검증하지 못 함
통합 테스트 (jest, jsdom, RTL)
컴포넌트에 대한 단위/통합 테스트 실행 - 렌더링 결과를 활용, jsdom으로 DOM 에뮬레이션 + React를 실행
특정 입력값(props)를 잘 렌더링하는지 테스트
실행 속도가 E2E에 비해 빠름
실제 브라우저가 필요한 기능은 테스트 불가, 프로덕션에서의 동작은 역시 검증 불가
E2E 테스트 (Playwright, reg-suit, Docker, DB, …)
실제 배포를 수행한 후 테스트. , 대부분의 경우 최대한 프로뎍션 환경과 유사하게 구성해 배포 환경, 테스트 사용자를 매번 생성/초기화, 외부 서버 대기, headless 브라우저 구동 및 렌더링 대기 수행
게시판 웹사이트에서 로그인/비로그인으로 CRUD를 실행 (성공/실패 검증)
실제 브라우저가 필요한 기능도 테스트 가능, 프로덕션 동작 검증 가능
다른 테스트에 비해 부하가 크고 실행 시간이 김
 

2. 테스트 자동화의 대상 및 적절 테스트 종류

  • RTL 사용 시 사용자 입장에서 DOM 환경에서 테스트하는 것으로, 테스트 대상이 Pure Component이더라도 통합 테스트로 보았습니다.
종류
설명
테스트 방법
테스트 방법론 선정 이유
컴포넌트 렌더링
초기 조건(props, context, …) 별 렌더링 결과 확인
컴포넌트 통합 테스트 (RTL)
jsdom으로 충분
컴포넌트 인터렉션
초기 조건 이후 인터렉션 발생 시의 응답 확인
컴포넌트 통합 테스트 (RTL)
jsdom으로 충분
컴포넌트 접근성
list, listitem, group, heading, button 등으로 조회가 가능한지 확인
컴포넌트 통합 테스트 (RTL)
jsdom으로 충분
이미지 업로드
upload 이벤트를 발행해 업로드를 이뮬레이트
컴포넌트 통합 테스트 (RTL)
jsdom으로 충분
시각적 회귀
중첩된 CSS로 실제 화면을 렌더링하고 이를 캡쳐해 전/후를 비교
E2E 테스트 (Playwright)
headless 브라우저 필요
라우팅 결과
실제로 해당 URL로 페이지 이동
E2E 테스트 (Playwright)
headless 브라우저 필요
화면 크기 기반의 동작
특정 화면 크기로 렌더링
E2E 테스트 (Playwright)
headless 브라우저 필요
반응형 스타일 검증
특정 화면 크기로 렌더링
E2E 테스트 (Playwright)
headless 브라우저 필요
스크롤 이벤트 기반의 동작
화면에서 실제로 스크롤 실행
E2E 테스트 (Playwright)
headless 브라우저 필요
cookie, session 기반의 동작
로그인 이후 화면을 재현해서 검증
E2E 테스트 (Playwright)
headless 브라우저 필요
브라우저 권한 허용/거절 동작 확인
브라우저 구동 시 권한 옵션으로 특정 권한들을 허용/거부
E2E 테스트 (Playwright)
headless 브라우저 필요
 

3. 테스트 작성 방법

 

3-1. 단위 테스트

  • 단순하게 Input, Output을 검증
    • 코딩 테스트에서 정답 여부를 가리는 방식과 동일
  • 단위 테스트 3단계 - AAA (Arrange, Act, Assert)
    • Arrange: Input을 준비
    • Act: 테스트 대상에 Input을 전달하고 실행
    • Assert: Output을 검증
  • 실행 환경 없이 단순하게 함수를 호출하고 검증하는 등의 방식

3-2. 컴포넌트 통합 테스트

  • 테스트 대상이 최소 단위가 아니며 여러 요소가 조합된 상태
    • (ex) RTL로 jsdom, React 환경에서 React Component를 렌더링하고 검증
  • mock을 자주 활용
    • next-router-mock
    • mock-service-worker
  • 입력 값
    • 컴포넌트
    • props
    • context
    • 이벤트 (fireEvent, userEvent)
  • 출력 값
    • role
      • 암묵적 role이 다수
    • text
      • alt text, title, placeholder, displayValue, …
  • 검증 방법
    • query (getBy, queryBy, findBy, …)
    • matcher (toBeInTheDocument, …)
 

3-3. E2E 테스트 (Playwright)

  • Playwright, reg-cli, …
  • Chrome을 headless로 활용해서 검증
  • Docker로 backend infra를 구축
  • 테스트가 병렬 실행되므로 테스트 사용자 재사용 불가
  • 전체 테스트를 실행 전/후로 데이터베이스 초기화
 

4. 다른 도구와 연동

 

4-1. Storybook 활용

  • UI 컴포넌트 탐색기 + 테스트 기능
  • play function으로 인터렉션 테스트 결과도 문서화 가능
    • storybook/test-runner 패키지로 Playwright로 play TC를 실행 가능
  • 컴포넌트 통합 테스트 시 Arrange 부분 공유 가능
    • storybook/testing-react 패키지로 Story를 TC로 사용 가능
  • mock 제공
    • storybook-addon-next-router
  • 그 외 addon
    • storybook-addon-accessibility
    • msw-storybook-addon
 

4-2. Storycap, reg-cli, reg-suit 활용

  • reg-cli: 이미지 diff 생성
    • 시각적 회귀 테스트 자동화에 사용
    • reg-cli는 두 디렉토리(actual, expected)를 비교해 diff 생성, 리포트 생성
  • storycap: 스토리북의 Story 모두 캡쳐
  • reg-suit: diff 비교, 리포트 생성