ANDROID TDD

[실행 환경을 기반으로 테스트 디렉터리 구성]

Android 스튜디오의 일반 프로젝트에는 테스트를 배치하는 두 개의 디렉터리가 포함되어 있습니다. 다음과 같이 테스트를 구성하세요.

• androidTest 디렉터리에는 실제 또는 가상 기기에서 실행되는 테스트가 포함되어야 합니다. 이러한 테스트에는 통합 테스트, 엔드 투 엔드 테스트 및 JVM만으로 앱 기능의 유효성을 검사할 수 없는 기타 테스트가 포함됩니다.

• test 디렉터리에는 로컬 시스템에서 실행되는 테스트(예: 단위 테스트)가 포함되어야 합니다.

[여러 유형의 기기에서 테스트를 실행하는 경우의 장단점 고려]

기기에서 테스트를 실행하는 경우 다음 유형 중에서 선택할 수 있습니다.

• 실제 기기

• 가상 기기(예: Android 스튜디오의 에뮬레이터)

• 시뮬레이션된 기기(예: Robolectric)

실제 기기는 가장 높은 충실도를 제공하지만 테스트를 실행하는 데 가장 많은 시간이 소요됩니다. 반면에 시뮬레이션된 기기는 낮은 충실도 대신 향상된 테스트 속도를 제공합니다. 그러나 플랫폼의 바이너리 리소스 및 사실적 루퍼 개선으로 시뮬레이션된 기기가 보다 사실적인 결과를 생성할 수 있습니다.

가상 기기는 충실도와 속도 간 균형을 제공합니다. 가상 기기를 사용하여 테스트하는 경우 테스트 간 설정 시간을 최소화하려면 스냅샷을 사용하세요.

 

[테스트 더블 사용 여부 고려]

출처 : http://xunitpatterns.com/Test%20Double.html 

 테스트 더블

• 메스자로스(Gerard Mezaros)가 "xUnitText Patterns"에서 만들어낸 용어로 테스트를 진행하기 어려운 경우 이를 대신해 테스트를 진행 할 수 있도록 만들어주는 객체를 말한다. * Mock 객체와 유사한 의미를 가지며 테스트 더블이 좀더 상위 의미로 사용된다.

더미객체(Dummy Object)

• 단순히 인스턴스화될 수 있는 수준으로만 객체를 구현한다.

• 인스턴스화된 객체가 필요할 뿐 해당 객체의 기능까지는 필요하지 않은 경우에 사용한다.

 테스트 스텁(Test Stub)

• 더미 객체 보다 좀더 구현된 객체로 더미 객체가 마치 실제로 동작하는 것처럼 보이게 단들어 놓은 객체이다.

• 객체의 특정 상태를 가정해서 만들어 특정 값을 리턴해 주거나 특정 메시지를 출력해 주는 작업을 한다.

• 특정 상태를 가정해서 하드코딩된 형태이기 때문에 로직에 따른 값의 변경은 테스트 할 수 없다.

페이크 객체(Fake Object)

• 여러 상태를 대표할 수 있도록 구현된 객체로 실제 로직이 구현된 것처럼 보이게 한다.

• 실제로 DB에 접속해서 비교할 때와 동일한 모양이 보이도록 객체 내부에 구현 할 수 있다.

  • 테스트케이스 작성을 위해서 다른 객체들과의 의존성을 제거하기 위해 사용한다.

  • 페이크 객체를 만들 때 복잡도로 인해서 노력이 많이 들어 갈 경우 적절한 수준에서 구현하거나, Mock 프레임 워크를 사용한다.

  • 페이크 객체를 생성하기 위한 노력이 많이 필요한 경우 실제 객체를 가져와 테스트 한다.

테스트 스파이(Test Spy)

• 테스트에 사용되는 객체, 메소드의 사용 여부 및 정상 호출 여부를 기록하고 요청시 알려준다.

• 테스트 더블로 구현된 객체에 자기 자신이 호출 되었을 때 확인이 필요한 부분을 기록하도록 구현한다.

• 특정 테스트 메서드가 몇번 호출 되었는지 필요한 경우 전역 변수로 카운트를 설정하고 특정 테스트 메서드에 카운트를 올리는 부분을 추가한 후 이 카운트를 가져오는 메서드를 추가한다.

• 아주 특수한 경우를 제외하고는 잘 쓰이지 않으며 보통 Mock 프레임워크에서 기본적으로 기능을 제공하므로 Mock을 사용한다.

• 특정 메소드가 호출 되었을 때 또 다른 메서드가 실행이 되어야 한다와 같은 행위 기반 테스트가 필요한 경우 사용한다.

Mock 객체(Mock Object)

• 행위를 검증하기 위해 사용되는 객체를 지칭하며 수동으로 만들 수도 있고 프레임워크를 통해 만들 수 있다.

• 행위 기반 테스트는 복잡도나 정확성등 작성하기 어려운 부분이 많기 때문에 상태 기반 테스트가 가능하다면 만들지 않는다.

• Mock 객체는 테스트 더블 하위객체로 써의 좁은 의미와 테스트 더블을 포함한 넓은 의미 2가지로 사용 될 수 있다.

[Android Test]

안드로이드 테스트는 크게 다음의 2가지가 있습니다.

• Unit Test

• Instrumentation Test

 

 

Unit Test 는 말 그대로 "단위 테스트"(함수 테스트)를 의미합니다. 흔히 TDD로 개발하게 되면, 매 "기능 단위별"로 테스트 코드를 구성하게 되고, 그 테스트 코드를 통과하는 실제 코드를 작성하곤 하지요. 혹은 그 반대도 가능하구요. 이때 사용되는 테스트 코드가 Unit Test 입니다.
해당 테스트를 수행하기 위해서는 module-name/src/test/java/ 하위에 테스트 코드를 작성하면 됩니다.

Android 컴포넌트들을 그대로 Unit Test 코드상에서 사용하면, 테스트는 실패합니다. Unit Test에서 사용하는 Android 컴포넌트들은 android-stubs-src.jar 파일을 참조하기 때문인데요, 해당 파일은 빈 껍데기(Stub)들만 모여있기에, 실행될 수 없습니다.
즉, 아래에서 설명하는 Instrumentation Test가 필요한 계기가 됩니다.

 

Instrumentation Test 는 실제 하드웨어 기기나 에뮬레이터에서 실행되는 테스트입니다. 안드로이드 환경에서 테스트하기 때문에 실제 Instrumentation Api 에 접근 가능합니다. Android 환경에서 실행되는 AndroidJUnitRunner를 통해서 실행됩니다.

해당 테스트는 module-name/src/androidTest/java/ 하위에 테스트 코드를 작성합니다. Instrumentation Test 는 Unit Test에 비해서, 그 속도가 느린 것이 단점입니다. 실제로 앱을 빌드 하고, 배포 하며, 실행 시키는 과정이 매 테스트마다 포함되기에 그렇습니다.

 

 

 

그래서 Unit Test에서 Instrumentation Api을 후킹할수 있도록 만들어진 것이 Mock Library입니다.