이 계측 테스트 카테고리는 일반적인 Android 애플리케이션을 타겟팅하는 카테고리와 다르지 않습니다. 계측을 포함하는 테스트 애플리케이션은 타겟팅하는 애플리케이션과 동일한 인증서로 서명되어야 합니다.
이 가이드에서는 개발자가 플랫폼 소스 트리 워크플로에 관해 이미 어느 정도 알고 있다고 가정합니다. 플랫폼 소스 트리 워크플로에 관해 잘 모른다면 https://source.android.com/source/requirements 페이지를 참고하시기 바랍니다. 여기에서 다루는 예는 자체 테스트 애플리케이션 패키지에 설정된 타겟 패키지로 새로운 계측 테스트를 작성하는 것입니다. 이 개념에 관해 잘 모른다면 플랫폼 테스트 소개를 읽어보세요.
이 가이드에서는 다음 테스트를 샘플로 제공합니다.
- frameworks/base/packages/Shell/tests
계속 진행하기 전에 먼저 코드를 탐색하여 대략적인 느낌을 파악하는 것이 좋습니다.
소스 위치 결정
계측 테스트는 애플리케이션을 타겟팅하므로 테스트 소스 코드를 플랫폼 소스 트리의 구성요소 소스 디렉터리 루트 아래에 있는 tests 디렉터리에 배치하는 것이 관례입니다.
자체 계측 테스트에 대한 엔드 투 엔드 예에서 소스 위치에 관한 자세한 설명을 참고하세요.
매니페스트 파일
일반 애플리케이션과 마찬가지로 각 계측 테스트 모듈에는 매니페스트 파일이 필요합니다. 파일 이름을 AndroidManifest.xml로 지정하고 테스트 모듈의 Android.mk 옆에 이 파일을 두면 BUILD_PACKAGE 핵심 makefile에서 자동으로 포함합니다.
계속 진행하기 전에 앱 매니페스트 개요를 반드시 먼저 살펴보시기 바랍니다.
매니페스트 파일의 기본 구성요소와 기능의 개요를 제공합니다.
샘플 gerrit 변경에 관한 매니페스트 파일의 최신 버전은 https://android.googlesource.com/platform/frameworks/base/+/master/packages/Shell/tests/AndroidManifest.xml에서 액세스할 수 있습니다.
편의를 위해 여기에 개요가 포함되어 있습니다.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.shell.tests">
<application>
<uses-library android:name="android.test.runner" />
<activity
android:name="com.android.shell.ActionSendMultipleConsumerActivity"
android:label="ActionSendMultipleConsumer"
android:theme="@android:style/Theme.NoDisplay"
android:noHistory="true"
android:excludeFromRecents="true">
<intent-filter>
<action android:name="android.intent.action.SEND_MULTIPLE" />
<category android:name="android.intent.category.DEFAULT" />
<data android:mimeType="*/*" />
</intent-filter>
</activity>
</application>
<instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
android:targetPackage="com.android.shell"
android:label="Tests for Shell" />
</manifest>
매니페스트 파일의 일부 리마크는 다음과 같습니다.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.shell.tests">
package 속성은 애플리케이션 패키지 이름입니다. 이는 고유한 식별자로 Android 애플리케이션 프레임워크에서 애플리케이션(여기서는 테스트 애플리케이션)을 식별하는 데 사용합니다. 시스템의 각 사용자는 해당 패키지 이름을 가진 애플리케이션을 하나만 설치할 수 있습니다.
이는 테스트 애플리케이션 패키지이므로 테스트 중인 애플리케이션 패키지와는 별도로 다른 패키지 이름을 사용해야 합니다. 일반적으로 접미사 .test를 추가하는 것이 관례입니다.
또한, 이 package 속성은 ComponentName#getPackageName()에서 반환하는 것과 동일하며 개발자가 adb shell을 통해 다양한 pm 하위 명령어와 상호작용하는 데 사용하는 것과 동일합니다.
패키지 이름은 일반적으로 자바 패키지 이름과 같은 형식이지만 실제로는 거의 관계가 없다는 점에 유의하세요. 즉, 애플리케이션(또는 테스트) 패키지에 포함되는 클래스는 어떤 패키지 이름이든 가질 수 있지만, 단순화하기 위해 애플리케이션 또는 테스트의 최상위 자바 패키지 이름을 애플리케이션 패키지 이름과 동일하게 할 수 있습니다.
<uses-library android:name="android.test.runner" />
이는 관련 클래스가 별도의 프레임워크 jar 라이브러리 파일에 패키징되므로 모든 계측 테스트에 필요합니다. 따라서, 애플리케이션 프레임워크에서 테스트 패키지를 호출할 때 추가 클래스 경로 항목이 필요합니다.
android:targetPackage="com.android.shell"
여기서는 계측의 타겟 패키지를 com.android.shell로 설정합니다.
am instrument 명령어를 통해 계측이 호출되면 프레임워크는 com.android.shell 프로세스를 다시 시작하고 계측 코드를 테스트 실행 프로세스에 삽입합니다. 이는 테스트 코드가 테스트 중인 애플리케이션에서 실행 중인 모든 클래스 인스턴스에 액세스할 수 있으며 노출된 테스트 후크에 따라 상태를 조작할 수 있다는 것을 의미합니다.
간단한 구성 파일
새로운 각 테스트 모듈에는 모듈 메타데이터, 컴파일 시간 종속 항목 및 패키징 지침으로 빌드 시스템을 안내할 구성 파일이 있어야 합니다. 대부분은 Soong 기반의 Blueprint 파일 옵션으로 충분합니다. 자세한 내용은 간단한 테스트 구성을 참고하세요.
복잡한 구성 파일
더욱 복잡한 테스트에는 Android 테스트 하네스, Trade Federation용 테스트 구성 파일도 작성해야 합니다.
테스트 구성에서는 특별한 기기 설정 옵션과 테스트 클래스 공급에 사용할 기본 인수를 지정할 수 있습니다.
샘플 gerrit 변경에 관한 구성 파일의 최신 버전은 frameworks/base/packages/Shell/tests/AndroidTest.xml에서 액세스할 수 있습니다.
편의를 위해 여기에 개요가 포함되어 있습니다.
<configuration description="Runs Tests for Shell.">
<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
<option name="test-file-name" value="ShellTests.apk" />
</target_preparer>
<option name="test-suite-tag" value="apct" />
<option name="test-tag" value="ShellTests" />
<test class="com.android.tradefed.testtype.AndroidJUnitTest" >
<option name="package" value="com.android.shell.tests" />
<option name="runner" value="android.support.test.runner.AndroidJUnitRunner" />
</test>
</configuration>
테스트 구성 파일의 일부 리마크는 다음과 같습니다.
<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
<option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>
지정된 target_preparer를 사용하여 대상 기기에 ShellTests.apk를 설치하도록 Trade Federation에 지시합니다. Trade Federation에는 개발자가 사용할 수 있는 타겟 준비자가 많으므로 테스트를 실행하기 전에 기기가 제대로 설정되어 있는지 확인하는 데 사용할 수 있습니다.
<test class="com.android.tradefed.testtype.AndroidJUnitTest">
<option name="package" value="com.android.shell.tests"/>
<option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>
이는 테스트를 실행하는 데 사용할 Trade Federation 테스트 클래스를 지정하고, 실행할 기기의 패키지와 테스트 실행자 프레임워크(이 경우 JUnit)를 전달합니다.
테스트 모듈 구성에 대한 자세한 내용은 여기를 참고하세요.
JUnit4 기능
android-support-test 라이브러리를 테스트 실행자로 사용하면 새 JUnit4 형식의 테스트 클래스를 채택할 수 있고 샘플 gerrit 변경에는 기능의 일부 기본적인 사용이 포함됩니다.
샘플 gerrit 변경에 관한 최신 소스 코드는 frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java에서 액세스할 수 있습니다.
테스트 패턴은 일반적으로 구성요소팀에 따라 다르지만, 일반적으로 유용한 사용 패턴이 있습니다.
@SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {
JUnit4의 주요 차이점은 테스트를 더 이상 공통 기본 테스트 클래스에서 상속하지 않아도 된다는 점입니다. 대신, 일반 자바 클래스로 테스트를 작성하고 주석을 사용하여 특정 테스트 설정 및 제약 조건을 표시합니다. 이 예에서는 이 클래스를 Android JUnit4 테스트로 실행하도록 지시합니다.
@SmallTest 주석으로 전체 테스트 클래스의 테스트 크기를 지정했으며 이 테스트 클래스에 추가된 모든 테스트 메서드는 이 테스트 크기 주석을 상속합니다. 사전 테스트 클래스 설정, 사후 테스트 해제 및 사후 테스트 클래스 해제는 JUnit4의 setUp 및 tearDown 메서드와 유사합니다.
Test 주석은 실제 테스트에 주석을 추가하는 데 사용됩니다.
@Before
public void setup() {
...
@Test
public void testGetProvider_shouldCacheProvider() {
...
@Before 주석은 JUnit4의 메서드에서 사전 테스트 설정을 실행하는 데 사용됩니다.
이 예에서는 사용되지 않지만, 사후 테스트 해제를 위한 @After도 있습니다.
마찬가지로, JUnit4의 메서드에서 @BeforeClass 및 @AfterClass 주석을 사용하여 테스트 클래스의 모든 테스트를 실행하기 전에 설정을 실행하고 이후 해제를 실행할 수 있습니다. 클래스 범위 설정 및 해제 메서드는 정적 메서드이어야 합니다.
테스트 메서드에 관해서는, JUnit의 이전 버전과는 달리 더 이상 메서드 이름을 test로 시작할 필요가 없으며 대신 각 메서드는 @Test로 주석을 달아야 합니다. 평소와 같이 테스트 메서드는 공개 상태여야 하며, 반환 값을 선언하지 않고, 매개변수를 사용하지 않습니다. 또한, 예외가 발생할 수 있습니다.
Context context = InstrumentationRegistry.getTargetContext();
JUnit4 테스트에는 더 이상 공통 기본 클래스가 필요하지 않으므로 기본 클래스 메서드의 getContext() 또는 getTargetContext()를 통해 Context 인스턴스를 가져올 필요가 없습니다. 대신, 새로운 테스트 실행자에서 계측 프레임워크가 만든 컨텍스트 및 환경 설정이 저장된 InstrumentationRegistry를 통해 인스턴스를 관리합니다. 이 클래스를 통해 다음을 호출할 수도 있습니다.
getInstrumentation():Instrumentation클래스의 인스턴스getArguments():-e <key> <value>를 통해am instrument에 전달되는 명령줄 인수
로컬에서 빌드 및 테스트
가장 일반적인 사용 사례에는 Atest를 사용하세요.
보다 심도 깊은 맞춤설정이 필요한 복잡한 사례인 경우 계측 안내를 따르세요.