자동화된 테스트는 다양한 방식으로 앱 품질을 개선하는 데 도움이 됩니다. 예를 들어 유효성 검사를 실행하고, 회귀를 포착하고, 호환성을 확인하는 데 도움이 됩니다. 좋은 테스트 전략을 사용하면 자동화된 테스트를 활용하여 중요한 이점인 개발자 생산성에 집중할 수 있습니다.
팀은 인프라 개선과 함께 체계적인 테스트 접근 방식을 사용할 때 생산성 수준을 높일 수 있습니다. 이렇게 하면 코드의 동작 방식에 관한 적절한 시기의 의견을 제공할 수 있습니다. 좋은 테스트 전략은 다음을 수행합니다.
- 문제를 최대한 빨리 포착합니다.
- 빠르게 실행됩니다.
- 문제를 해결해야 하는 경우 명확한 표시를 제공합니다.
이 페이지에서는 구현할 테스트 유형, 테스트를 실행할 위치, 테스트 실행 빈도를 결정하는 데 도움을 드립니다.
테스트 피라미드
최신 애플리케이션에서는 크기별로 테스트를 분류할 수 있습니다. 소규모 테스트는 코드의 작은 부분에만 집중하므로 빠르고 안정적입니다. 대규모 테스트는 범위가 넓고 유지관리하기 어려운 복잡한 설정이 필요합니다. 하지만 대규모 테스트는 충실도가 더 높고 한 번에 훨씬 더 많은 문제를 발견할 수 있습니다.
*충실도는 테스트 런타임 환경과 프로덕션 환경의 유사성을 나타냅니다.
대부분의 앱에는 많은 소규모 테스트와 상대적으로 적은 대규모 테스트가 있어야 합니다. 각 카테고리의 테스트 분포는 피라미드를 형성해야 합니다. 더 많은 소규모 테스트가 기본을 형성하고 더 적은 대규모 테스트가 팁을 형성합니다.
버그 비용 최소화
좋은 테스트 전략은 버그를 찾는 비용을 최소화하면서 개발자 생산성을 극대화합니다.
비효율적일 수 있는 전략의 예를 살펴보겠습니다. 여기서는 크기별 테스트 수가 피라미드로 구성되지 않습니다. 큰 엔드 투 엔드 테스트가 너무 많고 구성요소 UI 테스트가 너무 적습니다.
이는 병합 전에 실행되는 테스트가 너무 적다는 의미입니다. 버그가 있는 경우 야간 또는 주간 엔드 투 엔드 테스트가 실행될 때까지 테스트에서 버그를 포착하지 못할 수 있습니다.
버그를 식별하고 수정하는 비용에 미치는 영향과 테스트 노력을 더 작고 더 자주 실행되는 테스트로 편향하는 것이 중요한 이유를 고려해야 합니다.
- 버그가 단위 테스트에 포착되면 일반적으로 몇 분 안에 수정되므로 비용이 저렴합니다.
- 엔드 투 엔드 테스트에서는 동일한 버그를 발견하는 데 며칠이 걸릴 수 있습니다. 이로 인해 여러 팀 구성원이 참여하게 되어 전반적인 생산성이 저하되고 출시가 지연될 수 있습니다. 이 버그의 비용이 더 높습니다.
하지만 비효율적인 테스트 전략이라도 없는 것보다는 낫습니다. 버그가 프로덕션에 도달하면 수정사항이 사용자의 기기에 적용되는 데 시간이 오래 걸리며(때로는 몇 주) 피드백 루프가 가장 길고 비용이 많이 듭니다.
확장 가능한 테스트 전략
테스트 피라미드는 일반적으로 다음 3가지 카테고리로 나뉩니다.
- 단위 테스트
- 통합 테스트
- 엔드 투 엔드 테스트
하지만 이러한 개념에는 정확한 정의가 없으므로 팀에서 5개 레이어를 사용하는 등 카테고리를 다르게 정의할 수 있습니다.
- 단위 테스트는 호스트 머신에서 실행되며 Android 프레임워크에 종속되지 않는 단일 기능 단위 로직을 확인합니다.
- 예: 수학 함수의 1씩 차이 오류 확인
- 구성요소 테스트는 시스템의 다른 구성요소와 독립적으로 모듈이나 구성요소의 기능 또는 모양을 확인합니다. 단위 테스트와 달리 구성요소 테스트의 표면적은 개별 메서드와 클래스 위의 더 높은 추상화로 확장됩니다.
- 예: 맞춤 버튼의 스크린샷 테스트
- 기능 테스트는 두 개 이상의 독립적인 구성요소 또는 모듈의 상호작용을 확인합니다. 기능 테스트는 더 크고 복잡하며 일반적으로 기능 수준에서 작동합니다.
- 예: 화면의 상태 관리를 확인하는 UI 동작 테스트
- 애플리케이션 테스트는 배포 가능한 바이너리 형태로 전체 애플리케이션의 기능을 확인합니다. 테스트 중인 시스템으로 테스트 후크를 포함할 수 있는 개발자 빌드와 같은 디버깅 가능한 바이너리를 사용하는 대규모 통합 테스트입니다.
- 예: 폴더블의 구성 변경사항을 확인하는 UI 동작 테스트, 현지화 및 접근성 테스트
- 출시 후보 테스트는 출시 빌드의 기능을 확인합니다.
애플리케이션 바이너리가 축소되고 최적화된다는 점을 제외하고 애플리케이션 테스트와 유사합니다. 이는 앱을 공개 사용자 계정이나 공개 백엔드에 노출하지 않고 프로덕션과 최대한 유사한 환경에서 실행되는 대규모 엔드 투 엔드 통합 테스트입니다.
- 예: 중요한 사용자 여정, 성능 테스트
이 분류에서는 충실도, 시간, 범위, 격리 수준을 고려합니다. 여러 레이어에 다양한 유형의 테스트를 진행할 수 있습니다. 예를 들어 애플리케이션 테스트 레이어에는 동작, 스크린샷, 성능 테스트가 포함될 수 있습니다.
범위 |
네트워크 액세스 |
실행 |
빌드 유형 |
수명 주기 |
|
|---|---|---|---|---|---|
단위 |
종속 항목이 최소화된 단일 메서드 또는 클래스 |
아니요 |
로컬 |
디버그 가능 |
병합 전 |
구성요소 |
모듈 또는 구성요소 수준 여러 수업을 함께 진행 |
아니요 |
로컬 |
디버그 가능 |
병합 전 |
기능 |
기능 수준 다른 팀이 소유한 구성요소와의 통합 |
모의 |
로컬 |
디버그 가능 |
병합 전 |
애플리케이션 |
애플리케이션 수준 다른 팀에서 소유한 기능 또는 서비스와의 통합 |
모의 |
에뮬레이터 |
디버그 가능 |
병합 전 |
출시 후보 |
애플리케이션 수준 다른 팀에서 소유한 기능 또는 서비스와의 통합 |
프로덕션 서버 |
에뮬레이터 |
축소된 출시 빌드 |
병합 후 |
테스트 카테고리 결정
일반적으로 팀에 적절한 수준의 의견을 제공할 수 있는 피라미드의 가장 낮은 레이어를 고려해야 합니다.
예를 들어 로그인 흐름의 UI와 같은 이 기능의 구현을 테스트하는 방법을 생각해 보세요. 테스트해야 하는 항목에 따라 다른 카테고리를 선택합니다.
테스트 대상 |
테스트 대상에 대한 설명 |
테스트 카테고리 |
테스트 유형의 예 |
|---|---|---|---|
양식 유효성 검사기 로직 |
정규 표현식에 대해 이메일 주소를 검증하고 비밀번호 필드가 입력되었는지 확인하는 클래스입니다. 종속 항목이 없습니다. |
단위 테스트 |
|
로그인 양식 UI 동작 |
양식이 검증된 경우에만 사용 설정되는 버튼이 있는 양식 |
구성요소 테스트 |
Robolectric에서 실행되는 UI 동작 테스트 |
로그인 양식 UI 모양 |
UX 사양을 따르는 양식 |
구성요소 테스트 |
|
인증 관리자와 통합 |
인증 관리자에게 사용자 인증 정보를 전송하고 다양한 오류가 포함될 수 있는 응답을 수신하는 UI입니다. |
기능 테스트 |
|
로그인 대화상자 |
로그인 버튼을 누르면 로그인 양식이 표시되는 화면 |
애플리케이션 테스트 |
Robolectric에서 실행되는 UI 동작 테스트 |
중요한 사용자 여정: 로그인 |
테스트 계정을 사용하여 스테이징 서버에 대해 로그인 흐름을 완료합니다. |
출시 후보 버전 |
기기에서 실행되는 엔드 투 엔드 Compose UI 동작 테스트 |
어떤 항목이 특정 카테고리에 속하는지 여부는 주관적일 수 있습니다. 인프라 비용, 불안정성, 긴 테스트 시간과 같은 추가적인 이유로 테스트가 위 또는 아래로 이동할 수 있습니다.
테스트 카테고리가 테스트 유형을 결정하는 것은 아니며 모든 기능을 모든 카테고리에서 테스트해야 하는 것은 아닙니다.
수동 테스트도 테스트 전략의 일부가 될 수 있습니다. 일반적으로 QA팀에서 출시 후보 테스트를 수행하지만 다른 단계에 참여할 수도 있습니다. 예를 들어 스크립트 없이 기능의 버그를 탐색적으로 테스트합니다.
테스트 인프라
테스트 전략은 개발자가 지속적으로 테스트를 실행하고 모든 테스트가 통과되도록 보장하는 규칙을 적용할 수 있도록 인프라와 도구로 지원되어야 합니다.
범위별로 테스트를 분류하여 언제 어디에서 어떤 테스트를 실행할지 정의할 수 있습니다. 예를 들어 5계층 모델을 따르는 경우:
카테고리 |
환경 (위치) |
트리거 (시기) |
|---|---|---|
단위 |
[로컬][4] |
모든 커밋 |
구성요소 |
로컬 |
모든 커밋 |
기능 |
로컬 및 에뮬레이터 |
병합 전, 변경사항을 병합하거나 제출하기 전 |
애플리케이션 |
로컬, 에뮬레이터, 휴대전화 1개, 폴더블 1개 |
병합 후, 변경사항을 병합하거나 제출한 후 |
출시 후보 |
8개의 다양한 휴대전화, 1개의 폴더블, 1개의 태블릿 |
발표 전 |
- 단위 및 구성요소 테스트는 모든 새 커밋에 대해 지속적 통합 시스템에서 실행되지만 영향을 받는 모듈에 대해서만 실행됩니다.
- 모든 단위, 구성요소 및 기능 테스트는 변경사항을 병합하거나 제출하기 전에 실행됩니다.
- 애플리케이션 테스트는 병합 후에 실행됩니다.
- 출시 후보 테스트는 휴대전화, 폴더블, 태블릿에서 매일 밤 실행됩니다.
- 출시 전에 출시 후보 테스트가 많은 기기에서 실행됩니다.
테스트 수가 생산성에 영향을 미치는 경우 이러한 규칙은 시간이 지남에 따라 변경될 수 있습니다. 예를 들어 테스트를 야간 주기로 이동하면 CI 빌드 및 테스트 시간이 줄어들 수 있지만 피드백 루프가 길어질 수도 있습니다.