theme: apple-basic
layout: intro
highlighter: shiki
lineNumbers: true
¶ 안드로이드 테스트 자동화 기초
¶ 들어가기
- The History of Software Testing
- 1822년 찰스 베비지의 차분 엔진 제작
- 토마스 에디슨이 1878년 동료에게 보내는 편지
- 테스트 방법론
- 피라미드 vs 아이스크림 콘
- 테스트 커버리지 100%?
- 테스트 먼저 vs 구현 먼저
¶ 테스트 자동화의 필요성
- 테스트 유형
- 기능 테스트 : 내 앱이 기능을 수행합니까?
- 성능 테스트 : 빠르고 효율적으로 수행합니까?
- 접근성 테스트 : 접근성 서비스와 잘 작동합니까?
- 호환성 테스트 : 모든 기기와 API 수준에서 잘 작동합니까?
- 수동 테스트
- 빌드시간 증가, 비용 증가
- 자동 테스트
- 개발시간 감소, 비용 절감, 견고한 구조
¶ 자동 테스트의 분류
¶ 테스터 입장에서의 분류
- 블랙박스 테스트
- 화이트박스 테스트
ref) https://korea-sw-eng.blogspot.com/2017/04/1.html
¶ 자동 테스트의 분류
¶ 구글의 분류
ref) https://developer.android.com/training/testing/fundamentals
¶ 자동 테스트의 분류
¶ 단위 테스트 (Unit Test)
앱의 메서드 또는 클래스와 같은 작은 단위의 기능을 검증
-
로컬 단위 테스트 (Local Unit Test)
- Android Framework에 의존하지 않고 로컬 JVM에서 실행되는 테스트
- 실제 기기나 에뮬레이터를 사용하지 않으므로 테스트 속도가 빠름
-
계측 단위 테스트 (Instrumented Unit Test)
- Android Framework에 의존하는 기능을 검증하는 단위 테스트
- 실제 기기 또는 에뮬레이터에서 실행해야 하기 때문에 실행시간이 오래 걸림
¶ 자동 테스트의 분류
¶ 통합 테스트 (Intergration Test)
서로 다른 모듈 또는 클래스 간의 상호작용이 정상적으로 기능하는지를 검증
¶ 자동 테스트의 분류
¶ 종단간 테스트 (End-to-end Test)
앱의 전체 화면 또는 여러 모듈에 걸친 사용자 흐름과 같은 큰 부분에 대한 기능 검증을 수행
UI 테스트라 부르기도 함
¶ 테스트 사이즈
| Feature | Small | Medium | Large |
|---|---|---|---|
| Network access | No | localhost only | Yes |
| Database | No | Yes | Yes |
| File system access | No | Yes | Yes |
| Use external systems | No | Discouraged | Yes |
| Multiple threads | No | Yes | Yes |
| Sleep statements | No | Yes | Yes |
| System properties | No | Yes | Yes |
| Time limit (seconds) | 60 | 300 | 900+ |
ref) https://testing.googleblog.com/2010/12/test-sizes.html
¶ 테스트 기본 원칙
¶ Seven Testing Principles
- Testing shows the presence of defects, not their absence : 테스팅은 결함의 존재를 보여주는 것이다.
- Exhaustive testing is impossible : 완벽한 테스트는 불가능하다.
- Early testing saves time and money : 테스트 구성은 가능한 빠르게 시작한다.
- Defects cluster together : 결함은 군집되어 있다.
- Beware of the pesticide paradox : 살충제 역설 - 비슷한 테스트가 반복되면 새로운 결함을 발견할 수 없다.
- Testing is context dependent : 테스팅은 문맥에 의존적이다.
- Absence-of-errors is a fallacy : 오류 부재의 궤변 - 사용되지 않는 시스템이나 사용자의 기대에 부응하지 않는 기능의 결함을 찾고 수정하는 것은 의미가 없다.
¶ 테스트 기본 원칙
¶ F.I.R.S.T Principles
Fast: 단위 테스트는 빨라야 한다.Isolated: 테스트가 다른 테스트 케이스에 의존하지 않아야 한다.Repeatable: 테스트는 실행할 때마다 같은 결과를 만들어야 한다.Self-validating: 테스트 결과는 성공이거나 실패여야 한다. 결과에 대한 해석이 필요해서는 안된다.Timely: 단위 테스트는 기능이 출시된 후에도 언제든 작성할 수 있지만 적절한 시점은 프로덕션 코드를 구현하고 있는 와중에 테스트 코드를 작성하는 것이다.
¶ 테스트 코드 작성 스타일
¶ Given-When-Then 스타일
Given: 어떠한 상태하에서When: 어떠한 기능을 실행하면Then: 어떠한 결과가 나와야 한다.
@Test
fun x1_multiplyBy2_2() {
// GIVEN
val x = 1
// WHEN
val result = Utils.multipleBy2(x)
// THEN
assertEquals(2, result)
}
¶ Test Double
-
실제 구성요소 대신 테스트를 수행하는 객체
-
xUnit Test Patterns의 저자인 제라드 메스자로스(Gerard Meszaros)가 만든 용어
-
F.I.R.S.T Principles의
Isolated> 테스트 대상이 의존하는 것을 실제가 아닌 다른 것으로 대체
ref) http://xunitpatterns.com/Test%20Double.html
¶
¶ Test Double
¶ Dummy
- 인스턴스는 필요하지만 기능까지는 필요하지 않은 경우에 사용
interface AccountDao {
fun showMember()
}
class DummyAccountDao : AccountDao {
override fun showMember() : List<String> {
// No implementation
}
}
¶ Test Double
¶ Stub
- 인터페이스 혹은 클래스를 최소한으로 구현하고, 결과는 특정 상태를 가정해서 하드코딩된 값을 제공
- 상태 기반 테스트(State-based testing)에 사용
interface AccountDao {
fun showMember()
}
class StubAccountDao : AccountDao {
override fun showMember() : List<String> {
val memberList = listOf("Alice", "Bob")
return memberList
}
}
¶ Test Double
¶ Spy
- Stub과 비슷한 객체인데 추가적인 정보를 더 기록할 수 있게 구성
- 어떤 메소드 A가 호출 되었을 때 또 다른 메소드 B가 실행이 되었는지 확인하는 등의 행위 기반 테스트 (Interaction-based testing)에 사용
interface AccountDao {
fun showMember()
}
class SpyAccountDao : AccountDao {
private var callMemberCount = 0
override fun showMember() : List<String> {
val memberList = listOf("Alice", "Bob")
callMemberCount++
return memberList
}
}
¶ Test Double
¶ Fake
- 동작하는 구현이 있기에 테스트에는 사용할 수 있지만 프로덕션 구현과 동일하지는 않은 객체
interface AccountDb {
fun saveItem(userId: Int, name: String)
fun getItem(userId: Int) : String?
}
class FakeAccountDb : AccountDb {
private var accounts = HashMap<Int, String>()
init {
accounts[0] = "Alice"
accounts[1] = "Bob"
}
override fun saveItem(userId: Int, name: String) {
accounts[userId] = name
}
override fun getItem(userId: Int) : String? {
return accounts[userId]
}
}
¶ Test Double
¶ Mock
- Spy: 메소드 A와 B의 실제 동작을 추적, Mock: A가 실행되면 그냥 B의 정상 작동값을 반환하도록 구성
class Car(
private val engine: Engine,
private val dashboard: Dashboard
) {
fun start() {
engine.ignite()
dashboard.display()
}
}
class CarTest {
var engineMock: Engine = mock(Engine::class.java)
var dashboardMock: Dashboard = mock(Dashboard::class.java)
@Test
fun start_the_car() {
val car = Car(engineMock, dashboradMock)
car.start()
verify(engineMock).ignite()
verify(dashboardMock).display()
}
}
¶ 테스트 대상 항목
- 단위 테스트 대상
- ViewModels 또는 Presenter
- 데이터 레이어
- 유즈 케이스
- 값을 계산하는 유틸리티 클래스
- 엣지 케이스
- 음수, 0 및 경계 조건 을 사용하는 수학 연산
- 가능한 모든 네트워크 연결 오류
- 형식이 잘못된 JSON과 같은 손상된 데이터
- 파일 저장시 스토리지가 가득 찬 상황
- 프로세스 중간에 다시 생성된 개체(예: 장치가 회전할 때의 액티비티)
¶ 테스트 대상 항목
- UI 테스트
- 스크린 UI
- 유저 플로우
- 내비게이션
- 테스트 제외 대상
- 프레임워크 자체의 동작
- activities, fragments, 혹은 services에는 테스트가 필요한 로직을 가능한 배치하지 않음
ref) https://developer.android.com/training/testing/fundamentals/what-to-test
¶ 테스트 라이브러리
¶ Testing Framework
- JUnit4 : Java의 단위 테스트 코드를 작성하기 위해 만들어진 프레임워크로 Jetpack Test 라이브러리는 JUnit4를 기준으로 만들어져 있음. 현재 최신 버전은 JUnit5이나, 안드로이드를 완벽히 지원하지 않음.
- Kotest : Kotlin의 단위테스트 코드를 작성하기 위해 만들어진 프레임워크.
- Roboletric : JVM 만으로 안드로이드 프레임워크를 테스팅하기 위해 만들어진 프레임워크.
¶
¶ 테스트 라이브러리
¶ Assertion
Assertion의 표현력이 부족한 JUnit의 단점을 메워주는 라이브러리
// JUnit
assertTrue(notificationText.contains("testuser@google.com"));
// AssertJ, Truth
assertThat(notificationText).contains("testuser@google.com");
// Hamcrest
assertThat(notificationText, containsString("testuser@google.com"));
¶ 테스트 라이브러리
¶ Mocking
- Mockito : Java 테스트를 위한 Mocking 라이브러리
- MockK : Kotlin 테스트를 위한 Mocking 라이브러리
¶ 테스트 라이브러리
¶ UI Testing
-
Espresso : 단일 안드로이드 앱의 UI를 테스트하는 프레임워크
-
Kaspresso : KasperskyLab에서 제작한 안드로이드 앱 UI 테스트 프레임워크
-
Appium : iOS와 Android를 모두 테스트 할 수 있는 UI 테스트 프레임워크
-
UI Automator : 복수 앱 간의 UI 기능을 테스트하는 프레임워크
¶ 구글의 안드로이드 테스팅 환경
¶ Testing Related Video from Android Developers
- Android Testing (Android Dev Summit 2015)
- Test-driven development on Android with the Android Testing Support Library (Google I/O '17)
- Frictionless Android testing: Write once, run everywhere (Google I/O '18)
- Testing rebooted (with AndroidX Test) (Android Dev Summit '18)
- Testing Android apps at scale with Nitrogen (Android Dev Summit '18)
- Build testable apps for Android (Google I/O'19)
- What's new in Android testing tools | Session
¶ 구글의 안드로이드 테스팅 환경
¶ Jetpack Test Library
| Artifact | Stable Release |
|---|---|
| annotation | 1.0.0 |
| core | 1.4.0 |
| espresso | 3.4.0 |
| ext.junit | 1.1.3 |
| ext.truth | 1.4.0 |
| monitor | 1.5.0 |
| orchestrator | 1.4.1 |
| runner | 1.4.0 |
| rules | 1.4.0 |
| services | 1.4.1 |
¶ 구글의 안드로이드 테스팅 환경
¶ UI/Application Exerciser Monkey
-
Monkey는 에뮬레이터 또는 장치에서 실행되고 클릭, 터치 또는 제스처와 같은 사용자 이벤트의 의사 무작위 스트림과 여러 시스템 수준 이벤트를 생성
-
여러가지 옵션을 지정 가능
adb shell monkey [options] <event-count>
¶ 구글의 안드로이드 테스팅 환경
¶ Unified Test Platform
- Android Studio와 CI서버의 테스트 결과가 다르게 보고될 수 있음
¶ 구글의 안드로이드 테스팅 환경
¶ Unified Test Platform
- Android Studio Bumblebee 이상의 버전에서는 모든 계측 테스트가 통합된 Gradle Test Runner에서 실행
¶ 구글의 안드로이드 테스팅 환경
¶ Unified Test Platform
- 서로 다른 OS의 테스트를 모듈 방식으로 추가할 수 있고 병렬로 테스트를 수행할 수 있어서 테스트의 대규모화가 가능
¶ Code Coverage
- 내 코드가 얼마만큼 테스트 되고 있는지 평가할 수 있는 지표
- Java Code Coverage Library(JaCoCo)
¶ Code Coverage
¶ 어떤 코드가 테스트 하기 좋은 코드인가?
¶ CI/CD
- 프로덕트의 빌드 과정
- 연관된 의존성 다운로드
- 소스 코드를 바이너리 코드로 컴파일
- 바이너리 코드 링크하여 실행가능 파일로 패키징
- 테스트 수행
- 프로덕션 시스템에 배포
¶ CI/CD
- 지속적 통합(Continuous Integration, CI)
- 개발자가 코드를 작성하고 저장소에 커밋하면 자동으로 컴파일과 테스트를 수행
- 지속적 제공(Continuous delivery, CD)
- CI가 완료되어 배포할 수 있는 상태의 빌드 결과물을 저장소에 업로드 하는 것
- 지속적 배포(Continuous Deployment, CD)
- 지속적 제공 과정이 완료된 결과물을 최종 사용자가 사용할 수 있는 환경까지 자동으로 배포하는 솔루션
ref) https://www.redhat.com/ko/topics/devops/what-is-ci-cd