Google setzt sich dafür ein, die Rassengerechtigkeit für schwarze Gemeinschaften zu fördern. Siehe wie.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Targeting eines Anwendungsbeispiels

Diese Kategorie von Instrumentierungstests unterscheidet sich nicht wesentlich von denen, die auf die regulären Android-Anwendungen abzielen. Es ist erwähnenswert, dass die Testanwendung, die die Instrumentierung enthielt, mit demselben Zertifikat signiert sein muss wie die Anwendung, auf die sie abzielt.

Beachten Sie, dass in diesem Handbuch davon ausgegangen wird, dass Sie bereits über Kenntnisse im Plattform-Quellbaum-Workflow verfügen. Wenn nicht, lesen Sie bitte https://source.android.com/source/requirements. Das hier behandelte Beispiel ist das Schreiben eines neuen Instrumentierungstests mit einem Zielpaket, das in einem eigenen Testanwendungspaket festgelegt ist. Wenn Sie mit dem Konzept nicht vertraut sind, lesen Sie bitte die Einführung zum Testen der Plattform .

In diesem Handbuch wird der folgende Test als Beispiel verwendet:

  • Frameworks / Base / Pakete / Shell / Tests

Es wird empfohlen, zuerst den Code zu durchsuchen, um einen groben Eindruck zu erhalten, bevor Sie fortfahren.

Entscheidung für einen Quellort

Da der Instrumentierungstest auf eine Anwendung abzielt, besteht die Konvention darin, den Testquellcode in einem tests unter dem Stammverzeichnis Ihres Komponentenquellverzeichnisses im Plattformquellbaum abzulegen.

Weitere Diskussionen zum Quellspeicherort finden Sie im End-to-End-Beispiel für selbstinstrumentierende Tests .

Manifestdatei

Genau wie bei einer normalen Anwendung benötigt jedes Instrumentierungstestmodul eine Manifestdatei. Wenn Sie die Datei als AndroidManifest.xml und neben Android.mk für Ihr Testmodul bereitstellen, wird sie automatisch vom Kern-Makefile BUILD_PACKAGE .

Bevor Sie fortfahren, wird dringend empfohlen, zuerst die App-Manifest-Übersicht durchzugehen.

Dies gibt einen Überblick über grundlegende Komponenten einer Manifestdatei und deren Funktionen.

Auf die neueste Version der Manifestdatei für die Gerrit-Beispieländerung kann unter folgender Adresse zugegriffen werden: https://android.googlesource.com/platform/frameworks/base/+/master/packages/Shell/tests/AndroidManifest.xml

Ein Schnappschuss ist hier zur Vereinfachung enthalten:

 <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>
 

Einige ausgewählte Anmerkungen zur Manifestdatei:

 <manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">
 

Das package ist der Name des Anwendungspakets: Dies ist die eindeutige Kennung, mit der das Android-Anwendungsframework eine Anwendung identifiziert (oder in diesem Zusammenhang Ihre Testanwendung). Jeder Benutzer im System kann nur eine Anwendung mit diesem Paketnamen installieren.

Da es sich um ein .test handelt, muss unabhängig vom zu .test Anwendungspaket ein anderer Paketname verwendet werden: Eine übliche Konvention besteht darin, ein Suffix .test .

Darüber hinaus dieses package ist Attribut das gleiche wie das, was ComponentName#getPackageName() zurückkehrt, und auch die gleiche Sie mit verschiedenen zu interagieren würde pm Unterbefehle über adb shell .

Bitte beachten Sie auch, dass der Paketname normalerweise den gleichen Stil wie ein Java-Paketname hat, aber nur sehr wenige Dinge damit zu tun hat. Mit anderen Worten, Ihr Anwendungs- (oder Test-) Paket kann Klassen mit beliebigen Paketnamen enthalten. Andererseits können Sie sich für die Einfachheit entscheiden und Ihren Java-Paketnamen der obersten Ebene in Ihrer Anwendung oder Ihrem Test haben, der mit dem Namen des Anwendungspakets identisch ist.

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

Dies ist für alle Instrumentationstests erforderlich, da die zugehörigen Klassen in einer separaten Framework-JAR-Bibliotheksdatei gepackt sind und daher zusätzliche Klassenpfadeinträge erforderlich sind, wenn das Testpaket vom Anwendungsframework aufgerufen wird.

 android:targetPackage="com.android.shell"
 

Dadurch wird das com.android.shell.tests der Instrumentierung auf com.android.shell.tests . Wenn die Instrumentierung über den Befehl am instrument com.android.shell.tests wird, startet das com.android.shell.tests Prozess com.android.shell.tests neu und com.android.shell.tests Instrumentierungscode zur Testausführung in den Prozess ein. Dies bedeutet auch, dass der Testcode Zugriff auf alle Klasseninstanzen hat, die in der zu testenden Anwendung ausgeführt werden, und möglicherweise den Status abhängig von den offengelegten Test-Hooks ändern kann.

Einfache Konfigurationsdatei

Jedes neue Testmodul muss über eine Konfigurationsdatei verfügen, um das Build-System mit Modulmetadaten, Abhängigkeiten zur Kompilierungszeit und Packungsanweisungen zu steuern. In den meisten Fällen ist die Option Soong-basierte Blueprint-Datei ausreichend. Weitere Informationen finden Sie unter Einfache Testkonfiguration .

Komplexe Konfigurationsdatei

Für komplexere Tests müssen Sie auch eine Testkonfigurationsdatei für das Android-Testkabel Trade Federation schreiben.

In der Testkonfiguration können spezielle Geräte-Setup-Optionen und Standardargumente angegeben werden, um die Testklasse bereitzustellen.

Auf die neueste Version der Konfigurationsdatei für die Gerrit-Beispieländerung kann zugegriffen werden unter: frameworks / base / packages / Shell / tests / AndroidTest.xml

Ein Schnappschuss ist hier zur Vereinfachung enthalten:

 <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>
 

Einige ausgewählte Anmerkungen zur Testkonfigurationsdatei:

 <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
  <option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>
 

Dies weist Trade Federation an, die ShellTests.apk mit einem angegebenen target_preparer auf dem Zielgerät zu installieren. Entwicklern in Trade Federation stehen viele Zielvorbereitungen zur Verfügung, mit denen sichergestellt werden kann, dass das Gerät vor der Testausführung ordnungsgemäß eingerichtet wird.

 <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>
 

Dies gibt die Trade Federation-Testklasse an, die zum Ausführen des Tests verwendet werden soll, und übergibt das Paket auf dem auszuführenden Gerät und das Testrunner-Framework, das in diesem Fall JUnit ist.

Weitere Informationen zu Testmodul-Konfigurationen finden Sie hier

JUnit4-Funktionen

Die Verwendung der android-support-test Bibliothek als Test-Runner ermöglicht die Übernahme neuer Testklassen im JUnit4-Stil, und die Änderung des Beispiel-Gerrits enthält einige sehr grundlegende Funktionen.

Auf den neuesten Quellcode für die Beispiel-Gerrit-Änderung kann zugegriffen werden unter: frameworks / base / packages / Shell / tests / src / com / android / shell / BugreportReceiverTest.java

Während Testmuster normalerweise spezifisch für Komponententeams sind, gibt es einige allgemein nützliche Verwendungsmuster.

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

Ein wesentlicher Unterschied in JUnit4 besteht darin, dass keine Tests mehr erforderlich sind, um von einer gemeinsamen Basistestklasse zu erben. Stattdessen schreiben Sie Tests in einfachen Java-Klassen und verwenden Anmerkungen, um bestimmte Testeinstellungen und -einschränkungen anzugeben. In diesem Beispiel weisen wir an, dass diese Klasse als Android JUnit4-Test ausgeführt werden soll.

In der Annotation @SmallTest eine Testgröße für die gesamte @SmallTest angegeben: Alle dieser @SmallTest hinzugefügten Testmethoden erben diese Annotation für die Testgröße. Einrichtung der Pre-Test-Klasse, Post-Test- setUp und Post-Test-Class- setUp : Ähnlich den setUp und tearDown Methoden in JUnit4. Test Testanmerkung wird zum Annotieren des tatsächlichen Tests verwendet.

     @Before
    public void setup() {
    ...
    @Test
    public void testGetProvider_shouldCacheProvider() {
    ...
 

Die Annotation @Before wird von JUnit4 für Methoden verwendet, um die Einrichtung vor dem Test durchzuführen. Obwohl in diesem Beispiel nicht verwendet, gibt es auch @After für den @After nach dem Test. In ähnlicher Weise können die Annotationen @BeforeClass und @AfterClass für Methoden von JUnit4 verwendet werden, um das Setup durchzuführen, bevor alle Tests in einer Testklasse ausgeführt werden, und anschließend herunterzufahren. Beachten Sie, dass die Setup- und Teardown-Methoden für den Klassenbereich statisch sein müssen.

Anders als in früheren Versionen von JUnit müssen die Testmethoden den Methodennamen nicht mehr mit test , sondern müssen mit @Test . Wie üblich müssen Testmethoden öffentlich sein, keinen Rückgabewert deklarieren, keine Parameter annehmen und dürfen Ausnahmen auslösen.

         Context context = InstrumentationRegistry.getTargetContext();
 

Da für die JUnit4-Tests keine gemeinsame Basisklasse mehr erforderlich ist, müssen Context Instanzen nicht mehr über getContext() oder getTargetContext() über Basisklassenmethoden getTargetContext() werden. Stattdessen verwaltet der neue Testläufer sie über InstrumentationRegistry wo die vom Instrumentation Framework erstellten Kontext- und Umgebungseinstellungen gespeichert werden. Über diese Klasse können Sie auch anrufen:

  • getInstrumentation() : Die Instanz der Instrumentation Klasse
  • getArguments() : Die Befehlszeilenargumente, die über -e <key> <value> an ein am instrument werden

Lokal erstellen und testen

Verwenden Sie für die häufigsten Anwendungsfälle Atest .

Befolgen Sie bei komplexeren Fällen, die eine stärkere Anpassung erfordern, die Anweisungen zur Instrumentierung .