이 페이지에서는 다음을 포함하여 Android 앱 테스트의 핵심 원칙을 간략히 설명합니다. 각 권장사항과 이점을 배웁니다.
테스트의 이점
테스트는 앱 개발 프로세스에서 빼놓을 수 없는 부분입니다. 테스트 실행 어색하지 않게 함으로써 앱의 정확성, 기능적 성능 동작, 사용성 및 사용성을 고려하여 결정해야 합니다
앱을 탐색하여 수동으로 테스트할 수 있습니다. 다음과 같은 방법을 사용할 수 있습니다. 시스템 언어를 변경한 후 또는 모든 사용자 플로우를 통과할 수 있습니다.
하지만 수동 테스트는 확장성이 떨어지고 간과하기 쉽습니다. 앱 동작에서 회귀가 어떻게 발생할 수 있는지 확인하세요 자동 테스트에는 도구 사용이 포함됩니다. 더 빠르고 반복 가능하며 일반적으로 개발 초기에 앱에 대해 더 실행 가능한 피드백을 제공 프로세스입니다
Android의 테스트 유형
모바일 애플리케이션은 복잡하며 다양한 환경에서 잘 작동해야 합니다. 따라서 테스트에는 여러 유형이 있습니다.
제목
예를 들어 제목에 따라 다양한 유형의 테스트가 있습니다.
- 기능 테스트: 앱이 정상적인 작동을 하는가?
- 성능 테스트: 빠르고 효율적으로 실행하는가?
- 접근성 테스트: 접근성 서비스에서 잘 작동하나요?
- 호환성 테스트: 모든 기기 및 API 수준에서 제대로 작동하나요?
범위
테스트는 크기 또는 격리 수준에 따라서도 달라집니다.
- 단위 테스트 또는 소규모 테스트는 앱의 극히 일부분만 확인합니다. 예를 들면 메서드나 클래스입니다
- 엔드 투 엔드 테스트나 대규모 테스트를 통해 전체 화면 또는 사용자 플로우와 같은 동시 로드가 필요합니다.
- 중간 규모 테스트가 중간에 있으며 둘 이상의 테스트 간 통합을 확인합니다. 개 더 있습니다.
</ph>
테스트를 분류하는 방법에는 여러 가지가 있습니다. 그러나 가장 중요한 차이점은 여기는 테스트가 실행되는 곳입니다.
계측 테스트와 로컬 테스트 비교
Android 기기 또는 다른 컴퓨터에서 테스트를 실행할 수 있습니다.
- 계측 테스트: Android 기기에서 실제 또는 에뮬레이션된 테스트를 실행합니다. 이 앱은 명령어 및 코드를 삽입하는 테스트 앱과 함께 빌드 및 설치됩니다. 상태를 읽습니다. 계측 테스트는 일반적으로 앱을 실행하고 상호작용하게 됩니다.
- 로컬 테스트는 개발 머신 또는 서버에서 실행되므로 호스트 측 테스트라고도 합니다. 일반적으로 작고 빠르며 고립되어 있습니다. 앱의 나머지 부분에서 테스트 피사체를 분리합니다.
</ph>
모든 단위 테스트가 로컬 테스트는 아니고 모든 엔드 투 엔드 테스트가 기기에서 실행되는 것은 아닙니다. 예를 들면 다음과 같습니다.
- 대규모 로컬 테스트: 로컬에서 실행되는 Android 시뮬레이터를 사용할 수 있습니다. Robolectric으로 구현할 수 있습니다.
- 소형 계측 테스트: 코드가 프레임워크 기능을 지원하지 않습니다. 이 테스트는 여러 기기를 사용하여 여러 버전의 SQLite와의 통합을 확인할 수 있습니다.
예
다음 스니펫은 계측 UI 테스트: 요소를 클릭하고 다른 요소가 요소가 표시됩니다.
Espresso
// When the Continue button is clicked
onView(withText("Continue"))
.perform(click())
// Then the Welcome screen is displayed
onView(withText("Welcome"))
.check(matches(isDisplayed()))
Compose UI
// When the Continue button is clicked
composeTestRule.onNodeWithText("Continue").performClick()
// Then the Welcome screen is displayed
composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()
이 스니펫은 ViewModel (로컬, 호스트 측)의 단위 테스트의 일부를 보여줍니다. 테스트):
// Given an instance of MyViewModel
val viewModel = MyViewModel(myFakeDataRepository)
// When data is loaded
viewModel.loadData()
// Then it should be exposing data
assertTrue(viewModel.data != null)
테스트 전략 정의
이상적인 환경에서는 모든 기기에서 앱의 모든 코드를 테스트할 것입니다. 확인할 수 있습니다 안타깝게도 이 접근 방식은 너무 느리고 비용이 많이 듭니다
좋은 테스트 전략은 테스트 전략의 품질과 성능 간에 속도 및 안정성을 테스트해야 합니다 테스트 환경과 실험 환경 간의 유사성 테스트의 충실도는 실제 기기에서 결정됩니다. 고충실도 테스트는 에뮬레이트된 기기 또는 실제 기기 자체를 수집합니다. 낮은 충실도 테스트가 실행될 수 있음 JVM에서 실행됩니다 Hi-Fi 테스트는 속도가 느리고 더 많은 리소스가 필요하므로 모든 테스트가 충실도 높은 테스트가 아니어야 합니다.
불안정한 테스트
올바르게 설계되고 구현된 테스트 실행에서도 오류가 발생합니다. 예를 들어 실제 기기에서 테스트를 실행할 때 실패할 가능성이 높습니다. 코드의 미묘한 경합 상태로 인해 매우 드물게 발생합니다 100% 합격하지 못한 검사는 불안정합니다.
테스트 가능한 아키텍처
테스트 가능한 앱 아키텍처를 사용하면 코드가 여러 부분을 격리된 상태로 쉽게 테스트할 수 있습니다. 테스트 가능한 아키텍처에는 더 나은 가독성, 유지관리성, 확장성 및 있습니다
테스트할 수 없는 아키텍처에서는 다음을 생성합니다.
- 테스트가 더 크고 느리며 불안정합니다. 단위 테스트를 실행할 수 없는 클래스는 대규모 통합 테스트나 UI 테스트로 커버할 수 있어야 합니다
- 다양한 시나리오를 테스트할 기회가 줄어듭니다. 테스트가 클수록 속도가 느리지만 따라서 앱의 가능한 모든 상태를 테스트하는 것은 비현실적일 수 있습니다.
아키텍처 가이드라인에 대한 자세한 내용은 앱 가이드 아키텍처를 참고하세요.
분리에 대한 접근 방식
나머지에서 함수, 클래스 또는 모듈의 일부를 추출할 수 있는 경우 더 쉽고 효과적입니다. 이 방식을 디커플링이라고 하며 테스트 가능한 아키텍처에 가장 중요한 개념입니다.
일반적인 분리 기술에는 다음이 포함됩니다.
- 앱을 프레젠테이션, 도메인, 데이터와 같은 레이어로 분할합니다. 다음과 같은 작업을 할 수 있습니다. 앱을 기능당 하나씩 모듈로 분할하기도 합니다.
- 종속 항목이 큰 항목에는 사용할 수 있습니다. 이러한 클래스를 프레임워크의 진입점으로 사용하고 UI 및 비즈니스 로직을 컴포저블, ViewModel 또는 도메인 레이어와 관련이 있습니다.
- 비즈니스 로직을 포함하는 클래스에서 직접적인 프레임워크 종속 항목을 피합니다. 예를 들어 ViewModel에서 Android 컨텍스트를 사용하지 마세요.
- 종속 항목을 쉽게 교체할 수 있게 합니다. 예를 들어 인터페이스를 사용합니다. 사용 DI 프레임워크를 사용하지 않는 경우에도 종속 항목 삽입
다음 단계
이제 테스트해야 하는 이유와 두 가지 주요 테스트 유형을 알았으므로 테스트 항목을 읽어보세요.
또는 첫 번째 테스트를 만들어 직접 배우려면 테스트 Codelab을 참조하세요.