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

자체 계측 테스트 예

계측 테스트가 시작되면 실행을 위해 계측 코드가 삽입되고 시작되어 대상 패키지가 다시 시작됩니다. 한 가지 예외는 여기에서 대상 패키지가 Android 애플리케이션 프레임워크 자체인 android 패키지가 될 수 없다는 것입니다. 이는 이렇게 했을 때 계측을 포함하여 시스템 기능을 지원하는 Android 프레임워크를 다시 시작해야 하는 역설적인 상황으로 이어질 것이기 때문입니다.

이는 계측 테스트가 실행을 위해 시스템 서버인 Android 프레임워크에 직접 삽입될 수 없다는 의미입니다. Android 프레임워크를 테스트하기 위해 테스트 코드는 공개 API 표면, 또는 플랫폼 소스 트리에서 사용할 수 있는 Android 인터페이스 정의 언어(AIDL)를 통해 노출된 것만 호출할 수 있습니다. 이 테스트 카테고리에서는 특정 패키지를 타겟팅하는 것이 중요하지 않습니다. 따라서 이러한 계측은 AndroidManifest.xml의 자체 <manifest> 태그에 정의된 대로 자체 테스트 애플리케이션 패키지를 타겟팅하도록 선언하는 것이 일반적입니다.

요구사항에 따라 이 카테고리의 테스트 애플리케이션 패키지는 다음과 같습니다.

  • 테스트에 필요한 활동을 번들로 제공할 수 있습니다.
  • 사용자 ID를 시스템과 공유할 수 있습니다.
  • 플랫폼 키로 서명할 수 있습니다.
  • 공개 SDK가 아닌 프레임워크 소스에 대해 컴파일될 수 있습니다.

이 계측 테스트 카테고리는 경우에 따라 자체 계측이라고 합니다. 다음은 플랫폼 소스의 자체 계측 테스트 예입니다.

여기에서 다루는 예는 자체 테스트 애플리케이션 패키지에 설정된 타겟 패키지로 새로운 계측 테스트를 작성하는 것입니다. 이 가이드에서는 다음 테스트를 예로 사용합니다.

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

소스 위치 결정

일반적으로 개발자 팀에는 이미 코드를 체크인할 수 있는 장소 및 테스트를 추가할 수 있는 장소의 패턴이 확립되어 있습니다. 대부분의 팀은 단일 git 저장소를 소유하거나 다른 팀과 저장소를 공유하지만 구성요소 소스 코드가 포함된 전용 하위 디렉터리가 있습니다.

구성요소 소스의 루트 위치가 <component source root>에 있다고 가정하면 대부분의 구성요소에는 그 아래 srctests 폴더가 있고 Android.mk(또는 추가 .mk 파일로 분할), manifest 파일 AndroidManifest.xml, 테스트 구성파일 'AndroidTest.xml'과 같은 일부 추가 파일이 있습니다.

새 테스트를 추가하기 때문에 tests 디렉터리를 구성요소 src 옆에 만들고 콘텐츠로 채워야 할 수 있습니다.

경우에 따라 개별 apk에 여러 테스트 모음을 패키징해야 하므로 팀이 tests에 추가 디렉터리 구조를 보유할 수도 있습니다. 이 경우 tests에 새 하위 디렉터리를 만들어야 합니다.

구조와 관계없이 tests 디렉터리 또는 새로 만든 하위 디렉터리는 샘플 gerrit 변경의 instrumentation 디렉터리에 있는 파일과 유사한 파일로 채워집니다. 아래 섹션에서 각 파일에 대해 자세히 설명합니다.

manifest 파일

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

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

manifest 파일의 기본 구성요소와 기능의 개요를 제공합니다. platform_testing/tests/example/instrumentation/AndroidManifest.xml에서 예시를 참조하세요.

편의를 위해 여기에 개요가 포함되어 있습니다.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
        package="android.test.example.helloworld" >

        <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="21" />

        <application>
            <uses-library android:name="android.test.runner" />
        </application>

        <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
                         android:targetPackage="android.test.example.helloworld"
                         android:label="Hello World Test"/>

    </manifest>
    

manifest 파일의 일부 리마크는 다음과 같습니다.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
        package="android.test.example.helloworld" >
    

package 속성은 애플리케이션 패키지 이름으로, Android 애플리케이션 프레임워크가 애플리케이션(이 문맥에서는 테스트 애플리케이션)을 식별하는 데 사용하는 고유 식별자입니다. 시스템의 각 사용자는 해당 패키지 이름을 가진 애플리케이션 하나만 설치할 수 있습니다.

또한 이 package 속성은 ComponentName#getPackageName()이 반환하는 것과 동일하며 개발자가 adb shell을 통해 다양한 pm 하위 명령어와 상호작용하는 데 사용하는 것과 동일합니다.

패키지 이름은 일반적으로 자바 패키지 이름과 같은 형식이지만 실제로는 거의 관계가 없다는 점에 유의하세요. 즉, 애플리케이션(또는 테스트) 패키지에 포함되는 클래스는 어떤 패키지 이름이든 가질 수 있지만, 단순화하기 위해 애플리케이션 또는 테스트의 최상위 자바 패키지 이름을 애플리케이션 패키지 이름과 동일하게 할 수도 있습니다.

android:sharedUserId="android.uid.system"
    

이는 설치 시 이 apk에 핵심 플랫폼과 동일한 사용자 ID, 즉 런타임 ID를 부여해야 함을 선언합니다. 핵심 플랫폼(위 섹션의 LOCAL_CERTIFICATE 참조)과 동일한 인증서로 서명된 apk에 따라 다르지만 개념은 다양합니다.

  • 일부 권한 또는 API가 서명으로 보호되므로 동일한 서명 인증서가 필요함
  • 일부 권한 또는 API에는 호출자의 system 사용자 ID가 필요하며 핵심 플랫폼 자체와 별도의 패키지인 경우 호출 패키지가 사용자 ID를 system과 공유해야 함
<uses-library android:name="android.test.runner" />
    

이는 모든 계측 테스트에 필요합니다. 관련 클래스가 별도의 프레임워크 jar 라이브러리 파일로 패키징되기 때문입니다. 따라서 애플리케이션 프레임워크에서 테스트 패키지를 호출할 때 추가 클래스 경로 항목이 필요합니다.

android:targetPackage="android.test.example.helloworld"
    

여기서 targetPackage가 이 파일의 manifest 태그에 선언된 package 속성과 동일하게 선언되었음을 알 수 있습니다. 테스트 기본에서 언급했듯이 이 계측 테스트 카테고리는 일반적으로 프레임워크 API를 테스트하기 위한 것이므로 특정 대상 애플리케이션 패키지를 별도로 보유하는 것은 의미가 없습니다.

간단한 구성 파일

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

복잡한 구성 파일

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

테스트 구성에서는 특수한 기기 설정 옵션과 테스트 클래스를 제공할 기본 인수를 지정할 수 있습니다. /platform_testing/tests/example/instrumentation/AndroidTest.xml에서 예시를 참조하세요.

편의를 위해 여기에 개요가 포함되어 있습니다.

<configuration description="Runs sample instrumentation test.">
      <target_preparer class="com.android.tradefed.targetprep.TestFilePushSetup"/>
      <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
        <option name="test-file-name" value="HelloWorldTests.apk"/>
      </target_preparer>
      <target_preparer class="com.android.tradefed.targetprep.PushFilePreparer"/>
      <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer"/>
      <option name="test-suite-tag" value="apct"/>
      <option name="test-tag" value="SampleInstrumentationTest"/>

      <test class="com.android.tradefed.testtype.AndroidJUnitTest">
        <option name="package" value="android.test.example.helloworld"/>
        <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="HelloWorldTests.apk"/>
    </target_preparer>
    

Trade Federation에게 지정된 target_preparer를 사용하여 대상 기기에 HelloWorldTests.apk를 설치하도록 지시합니다. Trade Federation에는 개발자가 사용할 수 있는 대상 작성자가 많으므로 테스트를 실행하기 전에 기기가 제대로 설정되어 있는지 확인하는 데 사용할 수 있습니다.

<test class="com.android.tradefed.testtype.AndroidJUnitTest">
      <option name="package" value="android.test.example.helloworld"/>
      <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
    </test>
    

이는 테스트를 실행하는 데 사용할 Trade Federation 테스트 클래스를 지정하고, 실행할 기기의 패키지와 테스트 실행자 프레임워크(이 경우 JUnit)를 전달합니다.

자세한 내용은 테스트 모듈 구성을 참조하세요.

JUnit4 기능

테스트 실행자로 android-support-test 라이브러리를 사용하면 새 JUnit4 형식 테스트 클래스를 채택할 수 있으며 샘플 gerrit 변경사항은 기능의 기본적인 사용을 포함합니다. /platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.java에서 예시를 참조하세요.

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

@RunWith(JUnit4.class)
    public class HelloWorldTest {
    

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

    @BeforeClass
        public static void beforeClass() {
        ...
        @AfterClass
        public static void afterClass() {
        ...
        @Before
        public void before() {
        ...
        @After
        public void after() {
        ...
        @Test
        @SmallTest
        public void testHelloWorld() {
        ...
    

@Before@After 주석은 JUnit4가 메서드에서 사전 테스트 설정 및 사후 테스트 해체를 수행하는 데 사용됩니다. 마찬가지로 JUnit4가 메서드에서 @BeforeClass@AfterClass 주석을 사용하여 테스트 클래스에서 모든 테스트를 실행하기 전에 설정을 수행하고 이후 해체를 수행합니다. 클래스 범위 설정 및 해체 메서드는 정적이어야 합니다. 테스트 메서드에 관해서는, JUnit의 이전 버전과는 달리 더 이상 메서드 이름을 test로 시작할 필요가 없으며 대신 각 메서드는 @Test로 주석을 달아야 합니다. 평소와 같이 테스트 메서드는 공개 메서드여야 하고, 반환 값을 선언하지 않고 매개변수가 없으며, 예외가 발생할 수 있습니다.

중요: 테스트 메서드에는 @Test 주석이 달리며, APCT를 통해 테스트를 실행하려면 테스트 크기로 주석을 달아야 합니다. 예에서는 @SmallTest으로 testHelloWorld 메서드에 주석이 달렸습니다. 주석은 메서드 범위 또는 클래스 범위에서 적용될 수 있습니다.

instrumentation 액세스

기본적인 hello world 예제에서는 다루지 않지만 Android 테스트에서 액세스 Instrumentation 인스턴스를 요구하는 것이 일반적입니다. 애플리케이션 컨텍스트, 활동 수명 주기 관련 테스트 API 등에 대한 액세스를 제공하는 핵심 API 인터페이스입니다.

JUnit4 테스트는 더 이상 공통 기본 클래스를 필요로 하지 않으므로 더 이상 InstrumentationTestCase#getInstrumentation()을 통해 Instrumentation 인스턴스를 얻을 필요가 없습니다. 대신 새로운 테스트 실행자는 계측 프레임워크에 의해 생성된 컨텍스트 및 환경 설정이 저장된 InstrumentationRegistry를 통해 이를 관리합니다.

Instrumentation 클래스의 인스턴스에 액세스하려면 단순히 InstrumentationRegistry 클래스에서 정적 메서드 getInstrumentation()을 호출하면 됩니다.

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()
    

로컬에서 빌드 및 테스트

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

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