[우아한테크세미나] 시각적요소테스트자동화하기

요즘 테스트 자동화에 관심이 생겼는데 마침 우아한테크세미나에서 "시각적요소테스트자동화"를 주제로
세미나를 한다고 해서 참석해서 열심히 들어봤어요!
진짜 흥미롭게 설명 잘 해주시고 배울 것도 많은 세미나였습니다.
아래는 세미나를 들으면서 개인 복습 겸 기록용으로 정리한 내용입니다.
혹시 이렇게 블로그에 올리는 게 문제가 된다면 댓글 남겨주세요..!

테스트의 정의

• 테스트 : 널리 사용되기 전에 어떤 것의 품질, 성능, 신뢰성을 확립하기 위한 절차
• 소프트웨어 테스트 : 소프트웨어가 널리 사용되기 전에, 소프트웨어의 품질, 성능, 신뢰성을 확립하기 위한 절차
• 소프트웨어의 품질, 성능, 신뢰성 판단 기준 (특히 프론트엔드에서) :
  • 화면이 잘 그려지는가 ?
  • 기능이 잘 동작하는가 ?

테스트 자동화를 시도한 계기와 과정

1. 무엇을 테스트 했는가? (테스트 대상)

• 만다오 (Mandao). 만다오는 비개발자도 웹 GUI를 사용해 마크업 페이지와 간단한 동작을 셋업할 수 있고, URL 주소를 갖는 웹 페이지를
  생성해주는 프로그램. 우아한형제들의 다양한 어플리케이션에 사용되고 있다.
  주로 프로모션/이벤트 페이지 제작에 사용되는데, 사용되는 곳도 엄청 많고,
  배포 후에 화면이 제대로 그려지지 않거나 기능이 잘 동작하지 않으면
  큰 문제가 생길 수 있어서(이벤트 쿠폰의 금액이나 다운로드횟수제한 등이 잘못 들어간다던지ㄷㄷ)
  안정성을 보장하기 위해 테스트 자동화 방법을 구상해보게 됨.

2. 어떤 테스트를 했는가? (테스트 종류)

1) 시나리오 테스트

• 시나리오에 따라 동작을 어떻게 해야하는지 정의한 후, 시나리오에 따라 잘 동작하는지 테스트하는 것.
  (유저가 어떤 행동을 하는 시나리오를 작성한 뒤, 실제로 유저가 할 행동을 따라가보는 테스트 !)

2) 시각적 회귀 테스트

• 이전 상태를 스냅샷으로 찍어두고, 현재 상태와 비교해보는 테스트.
  화면의 렌더링 결과물이 스냅샷과 일치하는지 확인하는 테스트.

3) CSS 디버깅..?

• 악명 높은 CSS 디버깅.. E2E 테스트로 대체했다는 듯.
  (이 부분 제대로 이해를 못했어요)

3. 어떻게 테스트를 했는가? (테스트 방식)

블랙박스 테스트

• 블랙박스 테스트 :
  모듈 간의 상관관계를 알지 못하고, 코드가 보이지 않는 상태에서 입출력을 기준으로 작동을 확인하는 것.
  (input에 대해 예상되는 output이 나오는지 확인하는 것. )
  Ex) 결제가 잘 동작하는가? 버튼이 잘 눌러지는가? 에러 핸들링은 잘 되는가?
• 화이트박스 테스트 :
  모듈 안을 들여다보고 코드들이 모두 잘 실행되는지 확인하는 것.
  Ex) 모듈 1, 2, 3, 4, ... n 의 코드가 모두 실행되는가?
  코드를 통과하는 다른 시나리오는 없는가? (모든 시나리오를 커버하도록 작성되었는가?)
  예상된 Edge case는 잘 핸들링되는가?

=> 블랙박스 테스트를 선택해,
기존에 서빙되던 페이지들이 정상적으로 서빙되는지(=동일 input에 대해 동일 output이 보장되는지)를 확인함.

4. 테스트 구축하기

테스팅 툴

• Jest :
  JavaScript 테스팅 프레임워크. Node.js 프로세스를 사용해, 부가적인 라이브러리나 프레임워크 없이
  단독으로 잘 동작한다.
  코드 작성이 단순하고, jest-cli 설치만으로 별도의 환경설정 없이 바로 테스트를 실행하 수 있다.
  React, Vue 등의 프로젝트를 테스트하거나,
  비동기/병렬 테스트, 테스트 커버리지 확인, API mocking 등등.. 거의 다 가능하다.
• Puppeteer :
  Chromium 기반 자동화 도구.
  시각적 요소 테스트를 하려면 렌더링을 해야 하기 때문에 브라우저가 필요하다.
  Puppeteer는 브라우저에 대한 API 프로토콜로,
  브라우저에서 유저가 할 수 있는 행동을 코드화할 수 있다. (=시나리오의 코드화)
  즉, DOM 탐색 및 인터랙션, 브라우저 다이얼로그 상호작용 등등..
• -> Pueppeteer를 선택한 이유 : 브라우저 호환성이 좋고, 쉽고 빠르게 작성할 수 있고 사용하기 쉬워서
  (lean하게, 빠르게 일단 만들어보기 위한 용도로 적합)

테스트 구성

(디렉토리 구조 : src > test > e2e > tests 폴더 & config 파일들)

1) 필요한 패키지 설치

2) Config 작성

3) 테스트 작성

4) 테스트 구동

실제 테스트 구성하기

• 일반 텍스트, 마크업 텍스트, 유튜브 임베드, 이미지, 조건 블록, 반복 블록, 회전목마.. 등이 들어있는
  샘플 앱을 구성한다.
• 테스트용 로컬서버 구성 -> Chromium 실행 및 초기화 -> 시나리오 수행 및 단계별 이미지 스냅샷
  -> 스냅샷 비교
• 테스트 실행 환경에 따라 테스트가 깨지는 경우가 발생해,
  항상 동일한 테스트 환경에서 테스트를 진행할 수 있도록 별도의 테스트 환경도 구축함.
  (Docker 사용)

테스트 효용

• 구축한 테스트를 통해 실제로 에러를 검거한 사례가 있음.
• 에러가 검거된 부분은, 개발자가 관심있게 보는 부분과는 거리가 있는 부분이었기 때문에,
  수동으로 테스트했다면 놓치기 쉬울만한 부분이었다.
  (찾은 에러보다 무섭다는 못 찾은 에러, 방치되는 에러의 위험성)
• 테스트를 구축해두면, 코드를 업데이트할 때 사이드이펙트를 최소화하고 서비스 안정성을 확보할 수 있다.