Cette page a été traduite par l'API Cloud Translation.

Écrire un test sans périphérique côté hôte dans TF

Cette page vous explique comment écrire un test côté hôte qui ne nécessite pas de périphérique, tel qu'un test qui s'exécute sur une instance Linux GCE. (Pour plus de détails sur l'écriture d'un test piloté par l'hôte qui nécessite un périphérique, reportez-vous à Write a Host-driven test in Trade Federation .)

Types de tests côté hôte

Vous pouvez exécuter plusieurs types de tests côté hôte via Trade Federation (TF).

Tests natifs (gtest)

Créez des tests natifs (gtests) pour tester une plateforme. Si le test ne nécessite pas de périphérique, exécutez-le sur un hôte ; le test s'exécutera beaucoup plus rapidement de cette façon. Pour configurer de tels tests pour qu'ils s'exécutent sur un hôte de test, utilisez le coureur TF HostGTest .

Voici un exemple de configuration de test 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>

La configuration de test exécute un test gtest ( hello_world_test ) sur un hôte. L'exemple de configuration de test peut être généré automatiquement. À moins que votre test ne nécessite une configuration ou un nettoyage spécial, vous pouvez compter sur la génération automatique de configuration de test pour créer des configurations de test TF appropriées.

Pour configurer un gtest côté hôte et activer la génération automatique de configuration de test, définissez host_supported sur true dans Android.bp , comme dans hello_world_test .

Pour plus d'informations sur l'écriture d'un test natif, consultez Ajout d'un nouvel exemple de test natif .

Tests de l'hôte JAR

Les tests hôtes JAR (Java) , tels que JUnit, sont des tests qui n'ont pas besoin d'être exécutés sur un appareil et qui fournissent une couverture de code de votre projet Java. De tels tests peuvent être configurés pour s'exécuter sur un hôte de test à l'aide du runner HostTest .

Exemple de configuration de test TradeFed

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

La configuration de test exécute un test JUnit côté hôte de HelloWorldHostTest . Notez que la configuration de test ci-dessus peut être générée automatiquement. À moins que votre test ne nécessite une configuration ou un nettoyage spécial, comptez sur la génération automatique de configuration de test pour créer une configuration de test TradeFed appropriée.

Pour plus de détails sur la façon d'écrire un test d'hôte JAR, reportez-vous à la page Tests d'hôte JAR (Java) .

Tests d'hôtes Java isolés

Les tests Java sans périphérique peuvent être exécutés dans un environnement d'isolation avec un léger coût en termes de performances. Cependant, certaines considérations majeures doivent être prises en compte avant de choisir d’utiliser cet environnement.

Il s'agit du programme d'exécution par défaut utilisé pour les tests unitaires Robolectric et JUnit.
Tradefed prend en charge uniquement les tests JUnit dans l'environnement d'isolation.
Seules les dépendances liées statiquement sont prises en charge. Aucune dépendance déclarée avec lib n'est incluse dans le chemin de classe.
Le coureur d'isolation place uniquement le coureur de cale et votre pot de test sur le chemin de classe.
Il y a une certaine quantité de surcharge fixe par exécution de test exécutée avec ce programme d'exécution.

Exemple de configuration de test Tradefed (isolé)

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

Exemple de configuration Soong pour la génération automatique

Au lieu de créer manuellement la configuration de test comme ci-dessus , Soong peut générer automatiquement la configuration en utilisant une déclaration comme cet exemple.

java_test_host {
    name: "HelloWorldHostTest",

    test_options: {
        unit_test: true,
    },

    test_suites: ["general-tests"],

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

    static_libs: [
        "junit",
    ],
}

Tests robotiques

Les tests robotiques utilisent le même exécuteur que les tests d'hôtes isolés, avec quelques options spéciales.

L'option robolectric-resources permet de transmettre quelques options de ligne de commande spécifiques à Robolectric dans le sous-processus et ajoute la construction arborescente d' android-all au chemin de classe du sous-processus. Bien que les deux autres soient des bonnes pratiques, cette option est obligatoire pour exécuter des tests Robolectric avec succès.
L'option java-folder permet de modifier le runtime Java utilisé par le sous-processus. Cela est nécessaire car Robolectric préfère des versions Java particulières qui pourraient ne pas correspondre à la JVM préférée du système hôte.
L'option exclude-paths permet à l'exécuteur du sous-processus d'éviter de charger des modules particuliers, ce qui est utile lorsqu'un JAR est livré avec des classes superflues qui pourraient provoquer des erreurs de chargement. java. est une exclusion courante, pour éviter de lancer des exceptions SecurityException .

Exemple de configuration Robolectric

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

Exemple de configuration Soong pour l'autogénération roboélectrique

Au lieu de créer manuellement la configuration de test comme ci-dessus , Soong peut générer automatiquement la configuration en utilisant une déclaration comme cet exemple.

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",
}

Test Python

Si la logique de test est écrite en Python, utilisez le type de build python_test_host pour créer un fichier par qui peut être exécuté par TF PythonBinaryHostTest .

Exemple de configuration de test TradeFed

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

Paramètre de la suite de tests

Pour que le test côté hôte soit accessible par TF pour une build donnée, définissez le paramètre `test_suites` du module de test sur `general-tests` :

test_suites: ["general-tests"],

Avec ce paramètre, le test est empaqueté dans general-tests.zip sur la cible test_suites .