프론트엔드 테스트 전략 (시각적 테스트, 기능적 테스트)

NHN Cloud 채널 [2019] 실용적인 프런트엔드 테스트 전략 영상을 참고해 정리한 내용들이 포함되어 있습니다.

프론트엔드 테스트가 어려운 이유

입출력 값을 데이터로써 코드로 감지하기 쉽지 않습니다.

프론트엔드의 입력과 출력

입력 데이터	출력 데이터 (시각적 요소)
DOM 이벤트 : 마우스, 키보드, 터치 등 - 생성 : 브라우저의 이벤트 시뮬레이션 API 사용 라우팅/IO : URL 변경, 네트워크/로컬 파일, 로컬 스토리지/쿠키 - 생성 : 브라우저 API 목킹 / E2E 테스트 도구 사용	코드 관점 : HTML, CSS - 검증 : 생성된 HTML, CSS 코드의 내용을 비교 사용자 관점 : 브라우저가 렌더링한 화면 (픽셀 정보) - 검증 : 브라우저가 렌더링한 화면을 캡처해서 이미지로 비교

 

시각적 테스트

시각적 테스트 방식

방식	HTML 비교	시각적 회귀 테스트 (픽셀 비교)
사례	위 - HTML을 직접 문자열로 입력해서 비교한 방식 아래 - Jest를 이용해 스냅샷으로 비교하는 방식
한계	HTML 구조를 보고 실제 결과물을 예측할 수 없음. 테스트 성공이 항상 의도된 결과를 보장하지 않음. HTML/CSS 리팩토링에 도움이 되지 않음. 테스트 가이드에서 지양하는 방식에 해당 (구현 상세에 대한 테스트를 지양하고 동작을 테스트하라)	캡처 이미지의 신뢰성 문제 - 픽셀 단위 비교로 의미없는 변경점까지 인식 - 운영체제, 브라우저 등의 렌더링 방식 차이에도 영향받음. - 이미지/폰트 로딩 시간, 커서, 애니메이션 등으로 인한 캡처 시점 차이 결과 확인 및 이력 관리 - 커맨드 라인에서 확인 불가, 확인을 위한 UI 필요 - 케이스별 이미지 파일 히스토리 관리 필요 -> 유료 시각화 툴 탄생

 

시각적 테스트 도구 소개

Percy를 활용한 테스트 (유료 툴)

Storybook을 활용한 테스트

테스트 도구라기보다 컴포넌트를 분리해서 개발할 수 있게 해주는 개발 도구에 가깝습니다.
그러나 1) 시각적 요소 개발에 특화된 개발 환경을 제공해주고 2) 컴포넌트의 다양한 상태를 등록/관리할 수 있게 도와주고 있어 시각적 테스트를 위한 보조 도구로 사용하기 좋습니다.

Storybook 적용 전 엔트리 포인트를 각자 만들어 테스트를 해야 합니다.	Storybook 적용 후 여러 케이스를 간단하게 시각화하여 확인할 수 있습니다.

 

그 외에도

3)시각적 테스트에 부족한 설명적 기능을 보완해줄 수 있는 노트 기능이 있고
대부분의 4)시각화 테스트 도구와의 시너지를 낼 수 있습니다. (percy-storybook 조합)

 

Storybook 활용 범위

1. 디자인/기획 부서와의 커뮤니케이션
   • 디자인 QA를 위한 구현 결과물 공유
   • 구현 이슈나 프로토타이핑 결과를 공유하고 피드백 반영
   • 디자인 시스템 가이드 문서
2. 개발자간 커뮤니케이션
   • 공통 컴포넌트의 사용법 가이드 및 API 문서로 활용
   • 예제 페이지 / 튜토리얼 등의 문서로 활용
3. i18N 지원 기능 활용해 글로벌 UI 확인 가능

 

시각적 테스트 주의사항

제한적인 실행 환경과 느린 속도

• 스크린샷을 생성할 수 있는 환경에서만 테스트가 가능 (Selenium, Puppeteer)
• 테스트 실행 속도가 느려 개발 속도가 저하됩니다.
  
  

테스트의 문서화 기능이 없고 TDD 활용 불가

외부 영향을 너무 많이 받아 테스트가 실패했을 때 원인 파악이 어렵습니다.

 

기능적 테스트

테스트의 종류와 방식은 검색 결과가 많으므로 생략합니다.

주의사항 1 ) 시각적 요소 의존성 제거

시각적 요소와 관련된 클래스명을 이용하면 클래스명이나 DOM이 변경되었을 때 기능 테스트까지 깨지게 됩니다.
기능만을 위한 의미있는 클래스명을 부여하거나 데이터 속성을 이용하는 것이 좋습니다.

 

주의사항 2) 단위 테스트는 필수가 아니다

• 테스트 코드는 작성 및 유지보수, 컴퓨팅 시간/자원 등의 비용이 드니 불필요한 테스트는 최소화 해야 합니다.
• 복잡한 로직이 없는(trivial) 코드의 단위 테스트는 동어반복적(tautological)입니다.
• 시스템 테스트와 중복되는 단위 테스트는 제거하는 것이 좋습니다.
• 핵심 알고리즘을 갖는 모듈에 대한 단위 테스트는 여전히 중요합니다.
  
  

기능 E2E 테스트에 적합한 도구 추천 - Cypress

Cypress 프론트 엔드 개발자의 E2E 테스트에 적합한 도구입니다.

아래 표에 나와있듯이 Cypress는 브라우저 내부에서 실행되므로 브라우저의 디버깅 도구와 익스텐션 활용이 가능합니다.
UI 개발 환경면에서 Jest같은 커맨드 라인 환경보다 더 직관적이므로 TDD를 진행하기도 더 적합합니다.
손 쉬운 서버 요청과 응답 목킹이 가능하고 실행된 모든 명령의 히스토리/스냅샷/데이터 확인이 가능하다는 장점이 있습니다.

Jest 사용시보다 mock code가 단순해졌고 wait 필요없이 자동 적용해준다.

 

정리