このページは Cloud Translation API によって翻訳されました。

自己計測テストの例

インストルメンテーションテストが開始されると、インストルメンテーションコードが挿入され、実行のために開始された状態で、そのターゲットパッケージが再起動されます。 1 つの例外として、ここでのターゲットパッケージを Android アプリケーションフレームワーク自体、つまりパッケージandroidにすることはできません。これを行うと、インストルメンテーションを含むシステム機能をサポートする Android フレームワークを再起動する必要があるという逆説的な状況が発生するためです。自体。

つまり、インストルメンテーションテストは、実行のためにシステムサーバーとも呼ばれる Android フレームワークに自身を挿入することはできません。 Android フレームワークをテストするために、テストコードはパブリック API サーフェスのみ、またはプラットフォームソースツリーで利用可能な Android インターフェイス定義言語AIDLを介して公開されたサーフェスのみを呼び出すことができます。このカテゴリのテストでは、特定のパッケージを対象にすることは意味がありません。したがって、そのようなインストルメンテーションは、 AndroidManifest.xmlの独自の<manifest>タグで定義されているように、独自のテストアプリケーションパッケージを対象として宣言するのが通例です。

要件に応じて、このカテゴリのアプリケーションパッケージをテストすることもできます。

テストに必要なアクティビティをバンドルします。
ユーザー ID をシステムと共有します。
プラットフォームキーで署名されていること。
パブリック SDK ではなく、フレームワークソースに対してコンパイルされます。

このカテゴリの計測テストは、自己計測と呼ばれることがあります。プラットフォームソースでの自己インストルメンテーションテストの例を次に示します。

ここで説明する例は、独自のテストアプリケーションパッケージに設定されたターゲットパッケージを使用して、新しいインストルメンテーションテストを作成することです。このガイドでは、次のテストを例として使用します。

Hello World 計測テスト

続行する前に、まずコードを参照して大まかな印象をつかむことをお勧めします。

ソースの場所の決定

通常、チームは、コードをチェックインする場所とテストを追加する場所の確立されたパターンを既に持っています。ほとんどのチームは単一の git リポジトリを所有しているか、他のチームと共有していますが、コンポーネントのソースコードを含む専用のサブディレクトリを持っています。

コンポーネントソースのルートロケーションが<component source root>であると仮定すると、ほとんどのコンポーネントにはその下にsrcおよびtestsフォルダーがあり、 Android.mk (または追加の.mkファイルに分割) などのいくつかの追加ファイル、マニフェストファイルAndroidManifest.xml 、およびテスト構成ファイル「AndroidTest.xml」。

まったく新しいテストを追加するため、おそらくコンポーネントsrcの隣にtestsディレクトリを作成し、コンテンツを入力する必要があります。

場合によっては、さまざまなテストスイートを個々の apk にパッケージ化する必要があるため、チームがtestsの下にさらにディレクトリ構造を持つことがあります。この場合、 testsの下に新しいサブディレクトリを作成する必要があります。

構造に関係なく、 testsディレクトリまたは新しく作成されたサブディレクトリに、サンプルの gerrit 変更のinstrumentationディレクトリにあるものと同様のファイルを配置することになります。以下のセクションでは、各ファイルの詳細について説明します。

マニフェストファイル

通常のアプリケーションと同様に、各インストルメンテーションテストモジュールにはマニフェストファイルが必要です。ファイルにAndroidManifest.xmlという名前を付けて、テストモジュールのAndroid.mkの横に指定すると、 BUILD_PACKAGEコア makefile によって自動的に含まれます。

先に進む前に、まずアプリマニフェストの概要を確認することを強くお勧めします。

ここでは、マニフェストファイルの基本コンポーネントとその機能の概要を示します。 platform_testing/tests/example/instrumentation/AndroidManifest.xmlの例を参照してください。

便宜上、スナップショットがここに含まれています。

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

    <application/>

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

</manifest>

マニフェストファイルに関するコメントをいくつか選択します。

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

package属性はアプリケーションパッケージ名です。これは、Android アプリケーションフレームワークがアプリケーション (または、このコンテキストではテストアプリケーション) を識別するために使用する一意の識別子です。システム内の各ユーザーは、そのパッケージ名で 1 つのアプリケーションのみをインストールできます。

さらに、このpackage属性はComponentName#getPackageName()が返すものと同じであり、 adb shellを介してさまざまなpmサブコマンドと対話するために使用するものと同じです。

また、パッケージ名は通常、Java パッケージ名と同じスタイルですが、実際にはほとんど関係がないことに注意してください。言い換えると、アプリケーション (またはテスト) パッケージには任意のパッケージ名を持つクラスが含まれる可能性がありますが、単純にすることを選択して、アプリケーションまたはテストにアプリケーションパッケージ名と同じ最上位の Java パッケージ名を含めることもできます。

android:sharedUserId="android.uid.system"

これは、インストール時に、この apk にコアプラットフォームと同じユーザー ID、つまりランタイム ID を付与する必要があることを宣言します。これは、コアプラットフォームと同じ証明書で署名されている apk に依存することに注意してください (上記のセクションのLOCAL_CERTIFICATEを参照)。ただし、これらは異なる概念です。

一部の権限または 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 の大きな違いは、テストが共通の基本テストクラスから継承する必要がなくなったことです。代わりに、プレーンな Java クラスでテストを記述し、注釈を使用して特定のテスト設定と制約を示します。この例では、このクラスを 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 によってメソッドで使用され、テスト前のセットアップとテスト後のティアダウンを実行します。同様に、@BeforeClass および@BeforeClassアノテーションは、 @AfterClassによってメソッドで使用され、テストクラス内のすべてのテストを実行する前にセットアップを実行し、その後でティアダウンを実行します。クラススコープのセットアップメソッドとティアダウンメソッドは静的でなければならないことに注意してください。テストメソッドに関しては、以前のバージョンの JUnit とは異なり、メソッド名をtestで始める必要はなくなりました。代わりに、それぞれに@Testアノテーションを付ける必要があります。いつものように、テストメソッドはパブリックである必要があり、戻り値を宣言せず、パラメーターをとらず、例外をスローする場合があります。

重要: テストメソッド自体には@Testアノテーションが付けられます。テストをtestHelloWorld経由で実行するには、テストサイズで注釈を付ける必要があることに注意して@SmallTest 。アノテーションは、メソッドスコープまたはクラススコープで適用できます。

`instrumentation`へのアクセス

基本的な hello world の例ではカバーされていませんが、Android テストでInstrumentationインスタンスへのアクセスが必要になることはかなり一般的です。これは、アプリケーションコンテキスト、アクティビティライフサイクル関連のテスト API などへのアクセスを提供するコア API インターフェイスです。

JUnit4 テストは共通の基本クラスを必要としなくなったため、 InstrumentationTestCase#getInstrumentation()を介してInstrumentationインスタンスを取得する必要がなくなりました。代わりに、新しいテストランナーは、インストルメンテーションフレームワークによって作成されたコンテキストおよび環境設定が格納されるInstrumentationRegistryを介してインスタンスを管理します。

InstrumentationRegistryクラスのインスタンスにアクセスするには、 Instrumentationクラスで静的メソッドgetInstrumentation()を呼び出すだけです。

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

ローカルでビルドしてテストする

最も一般的な使用例では、 Atestを使用します。

高度なカスタマイズを必要とするより複雑なケースについては、インストルメンテーションの手順に従ってください。