Google은 흑인 공동체를 위한 인종 간 평등을 진전시키기 위해 노력하고 있습니다. Google에서 어떤 노력을 하고 있는지 확인하세요.

애플리케이션 타겟팅 예

이 계측 테스트 카테고리는 일반적인 Android 애플리케이션을 타겟팅하는 카테고리와 다르지 않습니다. 계측을 포함하는 테스트 애플리케이션은 타겟팅하는 애플리케이션과 동일한 인증서로 서명해야 합니다.

이 가이드에서는 개발자가 플랫폼 소스 트리 워크플로에 대해 이미 어느 정도 알고 있다고 가정합니다. 워크플로를 잘 모르는 경우, https://source.android.com/source/requirements 페이지를 참조하시기 바랍니다. 여기에서 다루는 예는 자체 테스트 애플리케이션 패키지에 설정된 타겟 패키지로 새로운 계측 테스트를 작성하는 것입니다. 이 개념에 대해 잘 모른다면 플랫폼 테스트 소개를 읽어보세요.

이 가이드에서는 다음 테스트를 샘플로 제공합니다.

  • frameworks/base/packages/Shell/tests

계속 진행하기 전에 먼저 코드를 탐색하여 대략적인 느낌을 파악하는 것이 좋습니다

소스 위치 결정

계측 테스트는 애플리케이션을 대상으로 하기 때문에 테스트 소스 코드를 플랫폼 소스 트리의 구성요소 소스 디렉터리 루트 아래에 있는 tests 디렉터리에 배치하는 것이 관례입니다.

자체 계측 테스트에 대한 엔드 투 엔드 예에서 소스 위치에 대한 자세한 설명을 참조하세요.

manifest 파일

일반 애플리케이션과 마찬가지로 각 계측 테스트 모듈에는 manifest 파일이 필요합니다. AndroidManifest.xml로 이름을 지정하고 테스트 모듈의 Android.mk 옆에 파일을 제공하면 BUILD_PACKAGE 핵심 makefile에서 자동으로 포함합니다.

계속 진행하기 전에 앱 manifest 개요를 먼저 살펴보시기 바랍니다.

manifest 파일의 기본 구성요소와 기능의 개요를 제공합니다.

샘플 gerrit 변경에 대한 manifest 파일의 최신 버전은 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 파일의 일부 리마크는 다음과 같습니다.

<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.tests로 설정합니다. am instrument 명령어를 통해 계측이 호출되면 프레임워크는 com.android.shell.tests 과정을 다시 시작하고 계측 코드를 테스트 실행 프로세스에 삽입합니다. 이는 테스트 코드가 테스트 중인 애플리케이션에서 실행 중인 모든 클래스 인스턴스에 액세스할 수 있으며 노출된 테스트 후크에 따라 상태를 조작할 수 있다는 것을 의미합니다.

간단한 구성 파일

각 새 테스트 모듈에는 모듈 메타데이터, 컴파일 타임 종속성 및 패키징 안내가 포함된 빌드 시스템을 안내하는 구성 파일이 있어야 합니다. 대부분의 경우 Soong 기반 청사진 파일 옵션으로 충분합니다. 자세한 내용은 간단한 테스트 구성을 참조하세요.

복잡한 구성 파일

보다 복잡한 경우에는 Android 테스트 하네스, Trade Federation용 테스트 구성 파일도 작성해야 합니다.

테스트 구성에서는 특수한 기기 설정 옵션과 테스트 클래스를 제공할 기본 인수를 지정할 수 있습니다.

샘플 gerrit 변경에 대한 구성 파일의 최신 버전은 https://android.googlesource.com/platform/frameworks/base/+/master/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>
    

Trade Federation에게 지정된 target_preparer를 사용하여 대상 기기에 ShellTests.apk를 설치하도록 지시합니다. 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.javast.java에서 액세스할 수 있습니다.

테스트 패턴은 일반적으로 구성요소 팀에 따라 다르지만 일반적으로 유용한 사용 패턴이 있습니다.

@SmallTest
    @RunWith(AndroidJUnit4.class)
    public final class FeatureFactoryImplTest {
    

JUnit4의 주요 차이점은 테스트가 더 이상 공통 기본 테스트 클래스에서 상속하지 않아도 된다는 점입니다. 대신 일반 자바 클래스로 테스트를 작성하고 주석을 사용하여 특정 테스트 설정 및 제약 조건을 표시합니다. 이 예에서는 이 클래스를 JUnit4 테스트로 실행하도록 지시합니다.

@SmallTest 주석은 전체 테스트 클래스에 대한 테스트 크기를 지정했습니다.이 테스트 클래스에 추가된 모든 테스트 메서드는 이 테스트 크기 주석을 상속합니다. 사전 테스트 클래스 설정, 사후 테스트 분해 및 사후 테스트 클래스 분해는 JUnit4의 특징인 tearDownsetUp과 유사합니다. 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()를 통해 Context 인스턴스를 가져오거나 기본 클래스 메서드를 통해 getTargetContext()를 가져올 필요가 없습니다. 대신 새로운 테스트 실행자는 계측 프레임워크에 의해 생성된 컨텍스트 및 환경 설정이 저장된 InstrumentationRegistry를 통해 이를 관리합니다. 이 클래스를 통해 다음을 호출할 수도 있습니다.

  • getInstrumentation(): Instrumentation 클래스에 대한 인스턴스
  • getArguments(): -e <key> <value>를 통해 am instrument에 전달된 명령줄 인수

로컬에서 빌드 및 테스트

가장 일반적인 사용 사례인 경우 Atest를 사용하세요.

보다 심도 깊은 맞춤설정이 필요한 복잡한 사례인 경우 계측 안내를 따르세요.