Diese Seite wurde von der Cloud Translation API übersetzt.

Schreiben Sie einen hostseitigen gerätelosen Test in TF

Auf dieser Seite erfahren Sie, wie Sie einen hostseitigen Test schreiben, der kein Gerät erfordert, beispielsweise einen Test, der auf einer Linux-GCE-Instanz ausgeführt wird. (Ausführliche Informationen zum Schreiben eines hostgesteuerten Tests, der ein Gerät erfordert, finden Sie unter „Schreiben eines hostgesteuerten Tests in Trade Federation “.)

Hostseitige Testtypen

Sie können über Trade Federation (TF) verschiedene Arten von Host-seitigen Tests durchführen.

Native (gtest) Tests

Erstellen Sie native Tests (gtests), um eine Plattform zu testen. Wenn für den Test kein Gerät erforderlich ist, führen Sie ihn auf einem Host aus. Der Test läuft auf diese Weise viel schneller. Um solche Tests für die Ausführung auf einem Testhost zu konfigurieren, verwenden Sie den TF-Runner HostGTest .

Dies ist eine Beispiel-Testkonfiguration von TradeFed:

<configuration description="Runs hello_world_test.">
    <option name="null-device" value="true" />
    <test class="com.android.tradefed.testtype.HostGTest" >
        <option name="module-name" value="hello_world_test" />
    </test>
</configuration>

Die Testkonfiguration führt einen gtest-Test ( hello_world_test ) auf einem Host aus. Die Beispieltestkonfiguration kann automatisch generiert werden. Sofern für Ihren Test keine spezielle Einrichtung oder Bereinigung erforderlich ist, können Sie sich auf die automatische Generierung von Testkonfigurationen verlassen, um ordnungsgemäße TF-Testkonfigurationen zu erstellen.

Um einen hostseitigen Gtest zu konfigurieren und die automatische Testkonfigurationsgenerierung zu aktivieren, setzen Sie host_supported in Android.bp auf true , wie in hello_world_test .

Weitere Informationen zum Schreiben eines nativen Tests finden Sie unter Hinzufügen eines neuen nativen Testbeispiels .

JAR-Hosttests

JAR (Java)-Hosttests wie JUnit sind Tests, die nicht auf einem Gerät ausgeführt werden müssen und die Codeabdeckung Ihres Java-Projekts bereitstellen. Solche Tests können mithilfe des Runners HostTest für die Ausführung auf einem Testhost konfiguriert werden.

Beispiel einer TradeFed-Testkonfiguration

<configuration description="Executes HelloWorldHostTest">
    <test class="com.android.tradefed.testtype.HostTest" >
        <option name="jar" value="HelloWorldHostTest.jar" />
    </test>
</configuration>

Die Testkonfiguration führt einen hostseitigen JUnit-Test von HelloWorldHostTest aus. Beachten Sie, dass die obige Testkonfiguration automatisch generiert werden kann. Sofern Ihr Test keine spezielle Einrichtung oder Bereinigung erfordert, verlassen Sie sich auf die automatische Generierung der Testkonfiguration, um die richtige TradeFed-Testkonfiguration zu erstellen.

Weitere Informationen zum Schreiben eines JAR-Hosttests finden Sie auf der Seite JAR-Hosttests (Java) .

Isolierte Java-Host-Tests

Gerätelose Java-Tests können in einer isolierten Umgebung mit geringen Leistungseinbußen ausgeführt werden. Bevor Sie sich für die Nutzung dieser Umgebung entscheiden, müssen jedoch einige wichtige Überlegungen angestellt werden.

Dies ist der Standard-Runner, der für Robolectric- und JUnit-Unit-Tests verwendet wird
Tradefed unterstützt nur JUnit-Tests in der Isolationsumgebung.
Es werden nur statisch verknüpfte Abhängigkeiten unterstützt. Im Klassenpfad sind keine mit lib deklarierten Abhängigkeiten enthalten.
Der Isolation Runner platziert nur den Shim Runner und Ihr Testglas auf dem Klassenpfad.
Pro Testlauf, der mit diesem Runner ausgeführt wird, entsteht ein gewisser fester Overhead.

Beispiel einer Tradefed-Testkonfiguration (isoliert)

<configuration description="Executes HelloWorldHostTest">
    <test class="com.android.tradefed.testtype.IsolatedHostTest" >
        <option name="jar" value="HelloWorldHostTest.jar" />
    </test>
</configuration>

Beispiel-Soong-Konfiguration für die automatische Generierung

Anstatt die Testkonfiguration wie oben manuell zu erstellen, kann Soong die Konfiguration automatisch generieren, indem er eine Deklaration wie dieses Beispiel verwendet.

java_test_host {
    name: "HelloWorldHostTest",

    test_options: {
        unit_test: true,
    },

    test_suites: ["general-tests"],

    srcs: ["test/**/*.java"],

    static_libs: [
        "junit",
    ],
}

Roboterelektrische Tests

Robolectric-Tests verwenden denselben Runner wie die isolierten Host-Tests, mit einigen besonderen Optionen.

Die Option robolectric-resources ermöglicht die Übergabe einiger Robolectric-spezifischer Befehlszeilenoptionen an den Unterprozess und fügt den Baumaufbau von android-all zum Klassenpfad des Unterprozesses hinzu. Während es sich bei den anderen beiden um Best Practices handelt, ist diese Option für die erfolgreiche Durchführung von Robolectric-Tests zwingend erforderlich .
Mit der Option java-folder können Sie die vom Unterprozess verwendete Java-Laufzeit ändern. Dies ist erforderlich, da Robolectric bestimmte Java-Versionen bevorzugt, die möglicherweise nicht mit der bevorzugten JVM des Hostsystems übereinstimmen.
Die Option exclude-paths ermöglicht es dem Subprozess-Runner, das Laden bestimmter Module überhaupt zu vermeiden. Dies ist nützlich, wenn eine JAR über irrelevante Klassen verfügt, die Ladefehler verursachen könnten. java. ist ein häufiger Ausschluss, um das Auslösen SecurityException Ausnahmen zu vermeiden.

Beispiel einer Robolectric-Konfiguration

<configuration description="Executes a Sample Robolectric Test">
    <option name="java-folder" value="prebuilts/jdk/jdk9/linux-x86/" />
    <option name="exclude-paths" value="java" />
    <option name="use-robolectric-resources" value="true" />
    <test class="com.android.tradefed.testtype.IsolatedHostTest">
        <option name="jar" value="RobolectricExampleTest.jar" />
    </test>
</configuration>

Beispiel-Soong-Konfiguration für die automatische Robolectric-Generierung

Anstatt die Testkonfiguration wie oben manuell zu erstellen, kann Soong die Konfiguration automatisch generieren, indem er eine Deklaration wie dieses Beispiel verwendet.

android_robolectric_test {
    name: "HelloWorldRoboTest",
    srcs: [
        "src/**/*.java",
    ],

    // Include the testing libraries
    static_libs: [
        "mockito-robolectric-prebuilt",
        "platform-test-annotations",
        "testng",
        "truth-prebuilt",
    ],

    instrumentation_for: "HelloWorldApp",
}

Python-Test

Wenn die Testlogik in Python geschrieben ist, verwenden Sie den Build-Typ python_test_host , um eine PAR-Datei zu erstellen, die von TF PythonBinaryHostTest ausgeführt werden kann.

Beispiel einer TradeFed-Testkonfiguration

<configuration description="Config to run atest unittests">
    <test class="com.android.tradefed.testtype.python.PythonBinaryHostTest" >
        <option name="par-file-name" value="atest_unittests" />
        <option name="test-timeout" value="2m" />
    </test>
</configuration>

Testsuite-Einstellung

Damit TF für einen bestimmten Build auf den hostseitigen Test zugreifen kann, setzen Sie die Einstellung `test_suites` des Testmoduls auf `general-tests` :

test_suites: ["general-tests"],

Mit dieser Einstellung wird der Test in general-tests.zip auf dem test_suites Ziel gepackt.