시각적 요소 테스트 자동화하기

2021.01.27 우아한 테크 세미나

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

💪TDD

👍이런 분께 추천해요!

• 배포 후 “여기 화면 깨졌어요“에 그만 철렁하고 싶은 프론트엔드 개발자

• 테스트가 좋다는데 뭐가 좋은지는 잘 안 와닿는 주니어 개발자

• 테스트 작성에 시간을 그만큼이나 쓴다는 개발자를 이해하기 어려운 PM

💪테스트

널리 사용되기 전에 어떤 것의 품질, 성능, 신뢰성을 확립하기 위한 절차

• 소프트웨어 테스트

• 오늘은 시각적 요소에 대한 테스트!

  • 화면이 잘 그려지는가?

  • 기능이 잘 동작하는가?

💪만다오

• 비개발자들도 쉽게 웹 GUI로 마켓 페이지를 생산해내는 서비스예요.

• 배포하고 화면이 깨지지 않을까?

  • 화면 깨진거는 그나마 괜찮아..

  • 근데 처음이 아닌 사람한테도 1만원을 뿌리게 되는 오류를 범하게 된다면? 😂😂

• 휴먼 에러를 최대한 줄여보자

• 시각적 요소 테스트 자동화!

💪어떤 테스트를 했나요?

시나리오 테스트

User가 어떤 동작을 할지에 대한 시나리오를 작성하고 실제로 유저가 할 행동을 따라해보는 테스트입니다.

시각적 회귀 테스트

• 렌더링 결과를 가지고 있다가 업데이트 되고 나서 겹쳐서 확인해봅니다.

• 차이가 발생하지 않아야합니다.

CSS 디버깅

• 안 되는데 왜 안 되는지 안 알려주는 CSS... 🤔

• 계속 코딩을 하다 보면 엉망진창이 되어버립니다.

• CSS 공식 문서에도 디버깅 안 되면 차 한잔 마시고 오라고 하고 있네요 😢

블랙박스 테스트

• 어떤 input이 들어가서 어떤 output이 나오는가?

• 결제가 잘 동작하는가?

• 버튼은 잘 눌러지는가?

• 에러 핸들링은 잘 되는가?

  • 예외 상황에 초점을 맞추지 않은 deep하지 않은 얕은 테스트

화이트박스 테스트

• 코드 안의 모든 모듈을 꼼꼼하게 점검

• 모든 시나리오를 작성

• 예상된 edge case는 잘 핸들링되는가?

💪테스팅 툴

Jest

• Facebook에서 만들었어요.

• JS 테스팅 프레임워크입니다.

• 코드도 되게 단순해서 많이 쓰이고 있어요.

할 수 있는 것

• React, Angular, Vue 등의 프로젝트의 테스트

• 비동기 / 병렬 테스트

• 테스트 커버리지확인

• API mocking

Puppeteer

• Chromium 기반 자동화 도구

• 유저 행동 코드화

  • 브라우저에서 유저가 할 수 있는 행동들을 코드로 작성할 수 있어요.

• 공식 문서 : 브라우저에 대한 API 프로토콜

• DOM 탐색 및 인터렉션

• 브라우저 다이얼로그 상호작용

• 브라우저와 상호작용할 수 있는 API이기 때문에 크롤링도 되고...

• ❗브라우저와의 상호작용이 가장 키 포인트입니다.

테스트 구성하기

1) 디렉토리 구조 확인

2) 필요한 패키지 설치

npm i --save-dev @types/jest-image-snapshot cross-env jest jest-image-snapshot jest-puppeteer puppetter ts-jest

3) Config 작성

• 첨부 필요

• 로컬이기 때문에 http 사용

• headless 모드 : true - node 안에서 false - 브라우저에서

4) 테스트 작성

5) 테스트 구동

• 차이나는 이미지를 (빨간색, 노란색) 결과로 보여줍니다.

---

💪만다오에 적용하기

• 시간이 그래도 몇 초 단위로 걸리기 때문에 모든 앱에 대해서 테스트는 못해요.

만다오가 제공하는 대부분의 기능을 담은 샘플 앱을 만들어요.

• Jest + 시나리오 기반 픽셀 매치 리그레션 방법을 사용합니다.

실제 사용하는 코드라고 합니다.

---

💪실제 테스트 구성 - 테스트 결과

모두 통과한다고 떴어요! 👉 진짜 그럴까요? 실제로는 깨질 수도 있어요.

• 누구의 컴에서는 가능하고 내 컴에서는 안 되는 케이스가 있을 수도 있어요.

그럼 테스트를 왜할까 싶죠? 👉 docker를 사용해야합니다.

• docker를 사용하여 테스트를 진행합니다.

  • 버전이 업데이트 되어도 만들어둔 docker 환경에서 그대로 테스트합니다.

---

💪쓸모 있었나요?

• 무엇 때문에 발생하는 에러인지 몰라도 테스트를 통해 확인이 가능해요.

• 실제로 원인을 모르는 렌더링 에러가 발생합니다.

• 그 무엇을 왜 모르냐구요? 아래와 같은 상황이 있거든요.

Feature 1 ← Module → Feature 2

-> Feature 1을 고치기 위해 코딩했는데 Feature 2에서 이상한 문제가 발생하는 경우도 있어요.

• 원인을 모르는 에러 생각보다 많아요. 이런 걸 다 테스트로 찾아낼 수 있는 거예요.

찾은 에러보다 무서운 못 찾은 에러

• 사이드 이펙트와 서비스 안정성

• 방치되는 에러들과 레거시 코드는 정말 위험해요.

• 테스트를 통해 관리할 수 있어서 좋습니다.

💪저희 팀도 테스트를 해야 할까요?

최소한의 안전성을 보장해주는 장치입니다.

• 단순히 개발뿐만 아니라 서비스가 안정적으로 업데이트 될 수 있다는 점에서 경영 측면에서도 필수입니다.

• 비용(시간)이 문제라고 할 수 있어요.

  • 3일짜리 프로모션인 경우 굳이~ 라고 생각이 들어요.
  • 하지만 서비스가 커지면 필수라고 생각합니다.

• 파일 6개 정도만 작성하면 첫 렌더링 페이지 정도 Test는 금방이예요!