스크린샷 테스트는 앱의 UI를 확인하는 매우 효과적인 방법입니다. 스크린샷 테스트는 구성요소, 기능, 애플리케이션 테스트에 있을 수 있습니다.
서드 파티 도구를 사용하여 계측 및 로컬 스크린샷 테스트를 모두 만들 수 있습니다. Compose를 사용하는 경우 공식 Compose 미리보기 스크린샷 테스트 도구를 사용할 수 있습니다.
정의
스크린샷 테스트는 UI의 스크린샷을 찍은 후 이전에 승인된 이미지('참조' 또는 '골드'라고 함)와 비교합니다.
이미지가 동일하면 테스트가 통과합니다. 차이가 있으면 도구에서 보고서를 만듭니다.
보고서를 통해 다음 두 가지 응답을 할 수 있습니다.
- 새 코드에 오류가 있음을 확인하고 수정합니다.
- 새 스크린샷을 승인하고 참조 이미지를 새 이미지로 교체합니다.
테스트 실패가 항상 오류가 있음을 의미하지는 않으므로 스크린샷 테스트의 워크플로는 일반 테스트와 다릅니다.
장점
스크린샷 테스트의 장점은 다음과 같습니다.
- 스크린샷 테스트는 테스트당 여러 어설션을 실행합니다. 예를 들어 단일 테스트로 색상, 여백, 크기, 글꼴을 확인할 수 있습니다.
- 스크린샷 테스트는 동등한 동작 테스트보다 작성, 이해, 유지 관리하기 훨씬 쉽습니다.
- 이는 다양한 화면 크기에서 회귀를 확인하고 포착할 때 특히 유용합니다.
단점
하지만 스크린샷 테스트에는 다음과 같은 단점도 있습니다.
- 대규모 프로젝트에서는 수천 개의 PNG가 생성될 수 있으므로 참조 이미지를 처리하는 것이 번거로울 수 있습니다.
- 플랫폼 (Linux, Max, Windows)에 따라 약간 다른 스크린샷이 생성됩니다.
- 동등한 동작 테스트보다 속도가 느립니다.
- 스크린샷 테스트가 많으면 문제가 발생할 수 있습니다(예: 단일 변경사항이 수천 개의 스크린샷에 영향을 미치는 경우).
다음 섹션에서는 이러한 문제를 해결하기 위한 권장사항을 제공합니다.
스크린샷 테스트 최소화
회귀의 피드백과 범위를 극대화하면서 스크린샷 테스트 수를 최소화해야 합니다.
다양한 UI 상태를 조합하면 테스트 수가 매우 빠르게 늘어날 수 있습니다. 다음은 앱 UI의 일부를 확인하는 방법 중 일부입니다.
- 다양한 테마
- 다른 글꼴 크기 사용
- 다양한 화면 크기 또는 경계 내부
앱의 모든 구성요소, 레이아웃, 화면에 이 작업을 실행하면 수천 개의 스크린샷 파일이 생성되며, 그중 대부분은 추가 의견을 제공하지 않습니다.
예를 들어 밝은 테마와 어두운 테마, 3가지 글꼴 크기로 맞춤 버튼을 테스트하려는 경우 모든 조합을 만들 필요는 없습니다. 대신 테마 중 하나만 선택할 수 있습니다. 이는 버튼이 긴 단어에 반응하는 방식이 테마에 영향을 미치지 않기 때문입니다.
참조 이미지 저장
참조 (또는 골드) 이미지는 일반적으로 소스 제어에 체크인할 수 있는 PNG 파일입니다. 그러나 Git 및 대부분의 소스 제어 관리자는 대용량 바이너리 파일이 아닌 텍스트 파일에 최적화되어 있습니다.
이러한 파일을 관리하는 방법에는 세 가지가 있습니다.
- git을 계속 사용하지만 저장용량 사용을 최소화하려고 합니다.
- Git LFS를 사용합니다.
- 클라우드 서비스를 사용하여 스크린샷을 관리합니다.
플랫폼 차이
스크린샷 테스트는 저수준 플랫폼 API를 사용하여 텍스트나 그림자와 같은 특정 기능을 그립니다. 플랫폼은 이를 다양한 방식으로 구현할 수 있습니다. Mac에서 개발하고 로컬에서 찍은 새 스크린샷을 저장하면 Linux CI 머신에서 테스트가 중단될 수 있습니다.
이 문제를 해결하는 방법에는 두 가지가 있습니다.
- 작은 변경 허용
- 서버에서 스크린샷 찍기
작은 변화 허용
두 스크린샷을 비교할 때 약간의 차이를 허용하도록 대부분의 스크린샷 테스트 라이브러리를 구성할 수 있습니다.
여기에는 두 가지 방법이 있습니다.
- 수정된 픽셀의 비율 또는 픽셀 값의 총 차이 비율을 기준으로 허용 오차를 구성합니다.
- 스크린샷을 비교하는 알고리즘인 스마트 디퍼를 사용하여 픽셀 대신 구조적 및 시맨틱 유사성을 확인합니다.
이 접근 방식의 단점은 거짓양성이 발생할 수 있고, 임곗값 미만이거나 유사하다고 잘못 간주되는 오류를 포착하지 못한다는 점입니다.
서버에서 스크린샷 찍기
픽셀 단위로 정확한 스크린샷 비교 도구를 사용하려면 테스트에서 동일한 조건으로 스크린샷을 찍어야 합니다. 이를 위해 지속적 통합 (CI) 시스템을 사용하거나 클라우드 서비스를 사용할 수 있습니다.
예를 들어 CI 워크플로에서 다음을 실행하는 단계를 만들 수 있습니다.
- 스크린샷 테스트를 실행합니다 (픽셀 정밀 일치를 사용하지 않는 경우에만 필요).
- 이전 단계가 실패한 경우 새 스크린샷을 기록합니다.
- 새 파일을 브랜치에 커밋합니다.
이 방법을 사용하면 CI에서 스크린샷 테스트가 실패하지 않지만 변경사항이 수정됩니다. 이렇게 하면 개발자와 변경사항 검토자가 변경사항을 병합하여 새 스크린샷을 수락할 수 있습니다.
스크린샷 테스트 도구
스크린샷 테스트에 사용할 수 있는 도구와 라이브러리의 다음과 같은 주요 차이점을 고려하세요.
- 환경: 호스트에서 실행되는 로컬 테스트 또는 에뮬레이터나 기기에서 실행되는 계측 테스트
- 렌더링 엔진: 호스트 측 스크린샷 솔루션은 Layoutlib(미리보기용 Android 스튜디오의 렌더링 엔진) 또는 Robolectric 네이티브 그래픽(RNG)을 사용할 수 있습니다.
- Layoutlib 기반 프레임워크는 정적 구성요소를 렌더링하는 데 중점을 두며, 서로 다른 상태를 사용하여 서로 다른 동작을 보여줍니다. 일반적으로 더 사용하기 쉽습니다.
- RNG와 통합되는 프레임워크는 Robolectric의 모든 기능을 사용할 수 있으므로 더 큰 범위의 테스트가 가능합니다.