UI 테스트, Chromatic

UI 테스트가 있으면 좋은 케이스

• 일부 컴포넌트의 변경 사항이 다른 컴포넌트들에 영향을 줄 확률이 높을 때
• 사람이 모든 사이드 이펙트를 예측하고 직접 눈으로 하나하나 확인하는데는 한계가 있을 때
• 테스트를 적용하여 제품의 안정성을 보장하고 싶을 때

 

UI 테스트 종류

수동 테스트

• 개발자가 컴포넌트의 정확성을 수동으로 확인하여 정확성을 검증
• 빌드 시 컴포넌트의 모양이 온전한지 확인하는 데 도움 됨

스냅샷 테스트

• Storyshots을 사용하여 컴포넌트가 렌더링 된 마크업을 캡쳐
• 렌더링 오류 및 경고를 유발하는 마크업의 변경사항을 파악하는데 도움 됨

단위 테스트

• 컴포넌트의 출력이 고정 입력값에서 동일하게 유지되는지를 확인
• 컴포넌트의 기능적 품질을 테스트하는데 유용
• 대표적으로 Jest 가 있음

시각적 회귀 테스트

• 실제 렌더링 되는 UI가 의도한 대로 보여지는지 테스트 가능
• 기존 UI를 캡쳐해놓고 변경된 UI와 비교하는 테스트 방식
• Chromatic, Percy, Applitools 등이 있음

 

---

Chromatic

장점

• 시각적 회귀 테스트를 통해 픽셀 단위의 변경 사항도 발견할 수 있어서 UI가 깨지거나 미세하게 변경되는 현상을 최대한 방지할 수 있다.
• 로그인해야 접근 가능하기 때문에 보안적인 문제는 없을 것 같다.
• Chromatic에서 지원하는 Github PR 자동화 기능을 활용하면 더 편리하게 사용할 수 있다.
• UI 변경 사항들이 기록되어서 히스토리 관리에 좋을 것 같다.
• 기존에는 UI 변경사항을 PR에서 코드로만 확인해야 해서 실제로 어떻게 렌더링 되는지 확인할 수 없는 아쉬움이 있었는데 직관적으로 UI를 확인하고 리뷰할 수 있다는 장점이 있다.
• 스토리북과 연동하여 사용할 수 있다.

단점

• 기존 UI를 캡쳐해놓고 비교하는 방식이기 때문에 UI가 일부만 깨져도 다른 UI들의 위치에 영향을 주어 모두 깨지는 것처럼 표현되어서 혼란스러울 수도 있을 것 같다. (하지만 일부 컴포넌트의 변화가 페이지 전체에 어떤 영향을 주는지 확인할 수 있어서 장점이 될 수도 있을 것 같다.)

 

Automatically review, test, and document Storybook