최근 TDD를 지향하면서 단위 테스트코드를 많이 짰습니다.
기능 테스트는 Jest로 큰 무리가 없었는데, UI 테스트 코드를 짤 때는 시각적으로 확인할 수 없어 답답함과 불안함이 있었습니다.
UI 테스트를 어떻게 진행할지 엄두가 안 났습니다. 꼼꼼하게 하자니 생산성이 바닥을 기어갈게 뻔했고, 그렇다고 대충 하거나 안 할 수도 없는 노릇이었습니다. 레이아웃이나 색이 변경되는 걸 어떻게 테스트할 수 있을까요? 그러던 차에 NHN FE개발랩의 김동우님이 발표하신 '실용적인 프런트엔드 테스팅 전략' 유튜브 영상을 봤고, Storybook을 한번 써보기로 했습니다.
시각적 요소 테스트
먼저 UI 테스트 요소에는 '시각적 요소', '구성 요소', '상호작용', '접근성', '유저 플로우'가 있습니다.
이번에는 소개해 볼 테스트는 시각적 요소 테스트입니다.
시각적 요소 테스트는 '컴포넌트가 props나 state에 따라 올바로 렌더링이 되는지 확인'하는 테스트이며, 스냅샷을 찍어 비교합니다.
깨진 레이아웃, 의도하지 않은 색깔 등은 모두 시각적 버그이며, 개발 과정에서 변경사항에 따른 이러한 버그는 필연적일 수 밖에 없습니다. 그만큼 해결하기 어려운 문제지만, 컴포넌트가 빌드될 때마다 그 모양이 같은지 확인해 주면 조금 더 안정적으로 코드를 수정할 수 있습니다.
테스트 순서
- 컴포넌트를 분리된 환경에서 렌더링하기. (테스트 환경 조성)
- 테스트 케이스 작성하기.
- 올바른 형태인지 개발자가 직접 확인하기.
- 버그 확인 자동화하기. (시스템 구축)
테스트 적용
저는 펫 프로젝트로 뽀모도로 앱을 만들고 있습니다. 이 앱에서 테스트해볼 것은 앱의 배경색 변화입니다.
배경색이 집중 시간에는 주황색, 짧은 휴식에는 연두색, 긴 휴식에는 파란색으로 변하게 되는지 테스트 해보겠습니다.
💡 뽀모도로
뽀모도로는 시간 관리 기법으로,
25분 집중과 짧은 휴식을 4번 반복한다.
마지막 휴식은 20분 정도로 길게 갖는다.
테스트 케이스 작성하기
props와 state의 변화를 통해 컴포넌트가 어떻게 변하는지 테스트 케이스를 만듭니다.
- Hourglass 컴포넌트에 대해 Focus, ShortBreaks, LongBreaks 테스트 케이스를 만들었습니다.
올바른 형태인지 개발자가 직접 확인하기
테스트 정답지를 만드는 과정입니다. 개발자가 직접 디자인 명세와 테스트 케이스가 일치하는지 확인합니다.
- 수정이 필요한 부분이 있다면 수정하며 정답을 완성해 나갑니다. 필요하다면 테스트 케이스를 추가/삭제합니다.
- 이미지 우측을 보면 컴포넌트에 어떤 props가 전달됐는지 확인할 수 있습니다.
버그 확인 자동화하기
'자동으로 회귀 포착'이라고도 하며, 커밋할 때마다 테스트 정답과 같은지 확인하는 시스템 구축합니다.
- 회귀 테스트 도구(ex. chromatic)를 사용해서 자동으로 확인합니다.
- 커밋마다 새 스냅샷이 캡처되고, UI 변경 사항을 감지합니다.
- 변경 사항이 발생했을 때, 의도한 것이라면 개발자는 accept, 아니라면 deny를 합니다.
- 이미지 우측을 보면 사각형에 연두색 표시가 있는데, 변경 내용을 표시한 것입니다.
- 깃허브에서 커밋을 보면 변경사항이 발생했을 때, 모두 accept가 되면 체크 표시가, 확인 중이면 갈색 동그라미 표시가 나타납니다.
마무리하며
사용한지 오래되지 않아 판단하기 조금 이르긴 하지만 지금까지 매우 만족스럽고, UI 테스트 도구로써 추천합니다.
다만, jest의 기능을 일부 사용할 수 있다는 점이 아쉬웠습니다.
현재 작업 중인 앱은 타이머가 핵심 기능인데, @storybook/test 라이브러리에서는 타이머를 아직 지원하지 않습니다.
아마 이 부분은 Cypress로 테스트를 해야 하지 않을까 생각이 들었습니다.
Storybook 팀이 공식 홈페이지에 튜토리얼을 보면 쉽게 따라 할 수 있습니다.
Storybook에 관심이 있으신 분은 Storybook Tutorial 공식 페이지에서 따라 해보시길 추천합니다.
출처
'테스트' 카테고리의 다른 글
| 스토리북 인터렉션 테스트는 왜 이렇게 잘 깨질까? (0) | 2025.03.27 |
|---|
