Android Testing android apps

사용 언어: Kotlin 1.8.10
사용 버전: Android Studio Electric Eel 2022.1.1 Patch 2
​

안드로이드 Testing android apps를 알아보겠습니다.

​
​
안드로이드 테스트에 대해서 알아보겠습니다. 
​
테스트 관련 문서는 아래에 있습니다.
​
https://developer.android.com/training/testing

테스트는 다음과 같은 장점이 있습니다.

실패에 대한 빠른 피드백.

빠른 오류 탐지.

안전하게 코드 리팩토링.

안정적인 속도로 개발.

​

​

안드로이드 앱을 테스팅 하는 기본적인 것들을 알아봅시다.

https://developer.android.com/training/testing/fundamentals

개발자가 직접 테스트를 진행할 수 있습니다. 시스템 언어를 변경한다든지, 다른 디바이스로 실행해 본다든지 등입니다. 하지만, 이러한 테스트는 놓치는 부분도 많고 좋지 않습니다.

따라서, 자동화된 테스트를 만들게 되면, 빠르고 쉽게 테스트할 수 있습니다.

​

테스트에는 목적과 범위에 따른 구분이 있습니다.

목적에 따라

기능적 테스트: 내 앱이 예상대로 작동하는지?

성능 테스트: 빠르고 효과적으로 시행되는지?

접근성 테스트: 접근성 기능들을 잘 제공하는지?

호환성 테스트: 모든 디바이스와 API level에서 잘 동작하는지?

​

범위에 따라

Unit tests 또는 small tests: 함수와 클래스 범위에서 테스트.

End-to-end tests 또는 big tests: 전체 화면 또는 user flow 테스트.

Medium tests는 여러 units을 통합하여 테스트.

​

​

테스트 위치에 따라서 장치에서 또는 내부에서 테스트하는 것으로 구분할 수 있습니다.

Instrumented tests는 실제 기기나 에뮬레이터를 실행하여 테스트하는 것을 말합니다. 보통 UI tests, 앱 실행, 상호작용을 테스트.

Local tests는 개발하던 장치 또는 서버에서 테스트합니다. 따라서 host-side tests라고도 불립니다. 전체 중에서 일반적으로 작고 빠른 독립된 주제에 대해서 테스트합니다.

​

​

모든 unit tests가 local이고, 모든 end-to-end 테스트가 instrumented가 아닙니다.

Big local test: 시뮬레이터에서 실행합니다. 예를 들면 Robolectric.

Small instrumented test: framework 특징에서 잘 작동하는지 확인합니다. 예를 들면 SQLite database가 있습니다. SQLite 여러 버전을 기기에서 통합하는 것입니다.

​

​

테스팅 전략 정의

좋은 테스트 전략은 테스트의 충실함과 속도 그리고 믿을 만 한가의 균형을 맞추는 것입니다. 실제 기기에 얼마나 환경이 비슷한가가 충실도를 결정합니다. 에뮬레이터 또는 실기기에서 테스트를 진행하면 높은 충실도입니다. 컴퓨터의 JVM 위에서 테스트를 하면 낮은 충실도입니다. 높은 충실도는 많은 리소스와 시간을 필요로 하므로 매번 높은 충실도로 진행할 필요는 없습니다.

​

Flaky tests

제대로 작성한 코드에서도 테스트 오류가 발생할 수 있습니다. 자동 업데이트가 실행되어 실패가 뜨기도 합니다.

​

​

테스트가 가능한 아키텍처

쉽게 테스트할 수 있는 아키텍처를 사용해야 합니다.

​

좋지 않은 아키텍처는

크고 느리고 많은 flaky tests를 사용합니다. class는 unit test가 불가능하고 bigger intergration tests or UI tests를 해야만 테스트가 가능합니다.

다른 시나리오로 테스트를 하기 어렵습니다. Bigger tests는 느리고 모든 가능성을 테스트하기에는 어렵습니다.

​

​

독립적으로 작동하는 접근법 decoupling

만약 function이나 class 또는 module을 전체에서 떼어내 테스트할 수 있다면 효과적이고 쉽게 테스트할 수 있을 겁니다. 이러한 것을 decoupling이라고 말합니다. 이러한 것은 테스트하기 좋은 아키텍처의 핵심 아이디어입니다.

Presentation, Domain, Data로 계층을 나눕니다. 또한 하나의 feature 당 module을 만들어서 나눕니다.

전체 로직을 거대한 의존성을 가지게 만들지 마세요. 예를 들면 activities 또는 fragments처럼 말이죠. 이러한 activity나 fragment는 framework의 Entry Points, 시작점으로 활용하고 UI와 business logic은 다른 곳으로 옮기세요. 예를 들면 Composable이나 ViewModel 또는 domain layer로 옮깁니다.

framework 의존성을 business logic에 추가하는 것을 피합니다. 예를 들면 ViewModel에 context를 사용하지 않는 것입니다.

의존성을 쉽게 대체할 수 있게 만듭니다. 단단하게 의존성을 사용하지 않고, 인터페이스를 사용합니다. 의존성 주입 라이브러리를 사용하지 않는다면, 의존성 주입을 수동으로 해줍니다.

​

​

​

끝.

​

카테고리: Android