Ausrichtung auf ein Anwendungsbeispiel

Diese Kategorie von Instrumentierungstests unterscheidet sich nicht wesentlich von denen, die auf die regulären Android-Anwendungen abzielen. Beachten Sie, dass die Testanwendung, die die Instrumentierung enthält, mit demselben Zertifikat signiert werden muss wie die Anwendung, auf die sie abzielt.

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

In diesem Leitfaden wird der folgende Test als Beispiel verwendet:

  • Frameworks/Basis/Pakete/Shell/Tests

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

Entscheidung für einen Quellort

Da die Instrumentierung Test wird eine Anwendung seines Targeting ist die Konvention des Test Quellcode in einem platzieren tests Verzeichnis unter der Wurzel Ihres Komponente Quellverzeichnis in Plattform - Source - Tree.

Sehen Sie mehr Diskussionen über die Quellenlage in der End-to-End - Beispiel für die Selbst instrumentiert Tests .

Manifestdatei

Genau wie eine normale Anwendung benötigt jedes Instrumentationstestmodul eine Manifestdatei. Wenn Sie die Datei als Namen AndroidManifest.xml und bieten sie neben Android.mk für Ihren Test tmodule, wird es automatisch vom bekommen enthalten BUILD_PACKAGE Kern Make - Datei.

Bevor Sie fortfahren, ist es sehr empfehlenswert durch die gehen App Manifest Übersicht zuerst.

Dies gibt einen Überblick über die grundlegenden Komponenten einer Manifestdatei und deren Funktionalitäten.

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

Der Einfachheit halber ist hier ein Schnappschuss 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 Attribut ist das Anwendungspaket Name: Dies ist die eindeutige Kennung , dass die Android Application Framework Anwendungen eine Anwendung zu identifizieren (oder in diesem Zusammenhang: Testanwendung). Jeder Benutzer im System kann nur eine Anwendung mit diesem Paketnamen installieren.

Da dies ein Testanwendungspaket, unabhängig vom Anwendungspaket im Test ist, muss ein anderer Paketname verwendet werden: eine gemeinsame Konvention ist ein Suffix hinzuzufügen .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 zwar 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, obwohl Sie sich andererseits der Einfachheit halber entscheiden und Ihren Java-Paketnamen der obersten Ebene in Ihrer Anwendung oder Ihrem Test identisch mit dem Anwendungspaketnamen verwenden können.

<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 verpackt sind und daher zusätzliche Klassenpfadeinträge erforderlich sind, wenn das Testpaket vom Anwendungsframework aufgerufen wird.

android:targetPackage="com.android.shell"

Damit wird das Zielpaket der Instrumentierung zu com.android.shell . Wenn die Instrumentierung über aufgerufen wird am instrument Befehl, der Rahmen neu gestartet com.android.shell Prozess und einspritzt Instrumentationscode in den Prozess für die Testausführung. Dies bedeutet auch, dass der Testcode Zugriff auf alle Klasseninstanzen hat, die in der getesteten Anwendung ausgeführt werden, und möglicherweise den Status abhängig von den exponierten Test-Hooks manipulieren kann.

Einfache Konfigurationsdatei

Jedes neue Testmodul muss über eine Konfigurationsdatei verfügen, um das Build-System mit Modul-Metadaten, Kompilierzeit-Abhängigkeiten und Verpackungsanweisungen zu leiten. In den meisten Fällen ist die auf Soong basierende Blueprint-Dateioption ausreichend. Siehe Einfache Testkonfiguration für weitere Einzelheiten.

Komplexe Konfigurationsdatei

Für komplexere Tests, müssen Sie auch eine Testkonfigurationsdatei für Android-Test harness, schreiben Trade Federation .

Die Testkonfiguration kann spezielle Geräteeinrichtungsoptionen und Standardargumente angeben, um die Testklasse bereitzustellen.

Die neueste Version der Konfigurationsdatei für die Probe gerrit Änderung kann abgerufen werden unter : Gerüste / base / packages / Shell / Tests / AndroidTest.xml

Der Einfachheit halber ist hier ein Schnappschuss 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 der Trade Federation stehen viele Zielvorbereitungsprogramme zur Verfügung, mit denen sichergestellt werden kann, dass das Gerät vor der Testausführung richtig eingerichtet ist.

<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 verwendet werden soll, um den Test auszuführen und das Paket auf dem auszuführenden Gerät und das Test-Runner-Framework, in diesem Fall JUnit, zu übergeben.

Schauen Sie hier für weitere Informationen über Testmodul Configs

JUnit4-Funktionen

Mit android-support-test - Bibliothek als Testläufer ermöglicht adoptieren neuer JUnit4 Stil Testklassen und die Probe gerrit Änderung enthält einige sehr einfache Nutzung ihrer Funktionen.

Neueste Quellcode für die Probe gerrit Änderung kann abgerufen werden unter : Gerüste / 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 Nutzungsmuster.

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

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

Die @SmallTest Annotation einer Testgröße für die gesamte Testklasse: alle Testmethoden ergänzt in dieser Test - Klasse erben diese Testgröße Anmerkung. Pre - Test - Klasse - Setup, Post - Test abzureißen, und nach Testklasse abzureißen: ähnlich wie setUp und tearDown Methoden in JUnit4. Test Anmerkung wird für Kommentierung des tatsächlichen Tests verwendet.

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

Die @Before Anmerkung wird auf Methoden , die von JUnit4 verwendet pre Prüfanordnung durchzuführen. Obwohl in diesem Beispiel nicht verwendet, gibt es auch @After für Post - Test Teardown. Ähnlich sind die @BeforeClass und @AfterClass sind Anmerkungen können auf Methoden , die von JUnit4 verwendet werden , Setup auszuführen , bevor alle Tests in einer Testklasse ausgeführt werden , und Abrüsten danach. Beachten Sie, dass die Setup- und Teardown-Methoden für den Klassenbereich statisch sein müssen.

Wie bei den Testverfahren, anders als in früheren Version von JUnit, sie nicht mehr benötigt den Namen der Methode , mit zu beginnen test , sondern jeder von ihnen muss mit Anmerkungen versehen wird @Test . Wie üblich müssen Testmethoden öffentlich sein, keinen Rückgabewert deklarieren, keine Parameter annehmen und können Ausnahmen auslösen.

        Context context = InstrumentationRegistry.getTargetContext();

Weil die JUnit4 Tests nicht länger eine gemeinsame Basisklasse erfordert, ist es nicht mehr notwendig , zu erhalten Context - Instanzen über getContext() oder getTargetContext() über die Basisklasse Methoden; Stattdessen schafft der neue Test Läufer sie über InstrumentationRegistry wo kontextuelle und Umwelt Setup durch Instrumentierung Rahmen geschaffen gespeichert wird. Über diese Klasse können Sie auch anrufen:

  • getInstrumentation() : die Instanz der Instrumentation Klasse
  • getArguments() : Die Befehlszeilenargumente zu übergeben am instrument über -e <key> <value>

Lokal bauen und testen

Für die häufigsten Anwendungsfälle beschäftigen Atest .

Für komplexere Fälle schwere Anpassung erfordern, befolgen Sie die Instrumentierung Anweisungen .