Playwright Visual comparisons를 활용해, 효율적으로 더 안전한 개발 환경 만들기

배경 및 문제 인식

• 프론트엔드 테스트는 UI 변경과 예측 불가한 사용자 입력으로 인해 어려움이 많음.
• 사람이 직접 검증하는 테스트는 한계가 있어 자동화된 테스트 도입을 고려.
• 기존 레코딩 방식의 E2E 테스트(TestProject, Playwright)는 유지보수 비용이 높고, UI 변경에 취약.

Playwright Visual Comparisons 도입

• UI의 변화를 감지하는 시각적 회귀 테스트 방식 적용.
• 기준 스크린샷을 저장하고, 코드 변경 후 비교하여 변경 사항을 검출.
• 2-up, Swipe, Highlight, Onion Skin 방식으로 이미지 비교 가능.

도입 과정에서 겪은 주요 문제와 해결책

1. 미세한 차이(0.01%)로 가짜 실패 발생
   문제: 테스트 실행 환경(OS, 브라우저, 디스플레이 설정 등)에 따라 폰트 렌더링 차이 발생.
   해결: Docker 컨테이너를 활용해 모든 테스트를 동일한 환경에서 실행.

2. 데이터 로딩 완료 후 스크린샷을 찍어야 하는 문제
   문제: 페이지가 완전히 로딩되기 전에 스크린샷을 찍으면, 로딩 UI가 포함되는 경우 발생.
   해결: getByText + toBeVisible을 활용하는 유틸리티 함수로 특정 문자열이 나타날 때까지 대기.

3. 애니메이션 요소로 인해 스크린샷 차이 발생
   문제: CSS 애니메이션, Canvas, SVG, WebGL 요소가 매번 다른 타이밍에 캡처됨 & flaky test가 됨.
   해결: 애니메이션 비활성화를 위한 각종 처리 및 부가적인 테스트 실행 효율화

4. 써드파티 플러그인(iframe 등)으로 인한 불필요한 변경 감지
   문제: 고객 피드백, 설문조사, 챗봇 등의 써드파티 플러그인이 iframe을 통해 로딩되며 시각적 변화 생성.
   해결: 스크린샷 생성 시 공통 css 처리를 통해 iframe과 특정 플러그인 요소를 보이지 않게 처리

5. 스크롤이 있는 페이지에서 하단 요소 검증 실패
   문제: toHaveScreenshot은 기본적으로 현재 보이는 화면만 캡처하여, 스크롤 관련 처리 필요
   해결: fullPage: true 옵션을 적용해 전체 페이지 스크린샷을 캡처하도록 설정.

결론

• 시각적 회귀 테스트를 통해 UI 변경 감지를 효과적으로 자동화함.
• 완벽한 솔루션은 아니지만, 개발 생산성과 테스트 안정성을 모두 향상시킴.
• 지속적인 개선과 테스트 환경 최적화가 필요함.