Structure AndroidTest.xml

La structure globale de la configuration du module suit un modèle semblable à celui de la configuration XML Tradefed standard, mais avec quelques restrictions, car elle s'exécute dans le cadre d'une suite.

Liste des balises autorisées

AndroidTest.xml ou, plus généralement, la configuration du module ne peut contenir que les balises XML suivantes : target_preparer, multi_target_preparer, test et metrics_collector.

Bien que cette liste semble restrictive, elle vous permet de définir précisément les besoins de configuration du module de test et le test à exécuter.

REMARQUE : Consultez la configuration XML Tradefed si vous avez besoin de vous rappeler les différentes balises.

Les objets tels que build_provider ou result_reporter génèrent une ConfigurationException si vous tentez de les exécuter à partir d'une configuration de module. Cela permet d'éviter que ces objets n'effectuent réellement une tâche à partir d'un module.

Exemple de configuration de module

<configuration description="Config for CTS Gesture test cases">
    <option name="test-suite-tag" value="cts" />
    <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsGestureTestCases.apk" />
    </target_preparer>
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="android.gesture.cts" />
        <option name="runtime-hint" value="10m50s" />
    </test>
</configuration>

Cette configuration décrit un test qui nécessite l'installation de CtsGestureTestCases.apk et exécute une instrumentation sur le package android.gesture.cts.

Balises d'inclusion <include> et <template-include>

L'utilisation de <include> et <template-include> dans les configurations de module est déconseillée. Leur fonctionnement n'est pas garanti.

Cas particulier pour la balise metrics_collector

La balise metrics_collector est autorisée, mais limitée à la FilePullerLogCollector classe afin de spécifier un fichier ou un répertoire donné à extraire et à enregistrer pour le module. Cela est utile si vous laissez des journaux dans un emplacement particulier et que vous souhaitez les récupérer automatiquement.

Exemple de configuration :

<configuration description="Config for CTS UI Rendering test cases">
    <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
    </target_preparer>
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="android.uirendering.cts" />
        <option name="runtime-hint" value="11m55s" />
        <option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
        <option name="isolated-storage" value="false" />
    </test>

    <!-- Collect the files in the dump directory for debugging -->
    <metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
        <option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
        <option name="collect-on-run-ended-only" value="true" />
    </metrics_collector>
</configuration>

Qu'en est-il des informations de compilation ou des téléchargements ?

La définition des balises autorisées peut donner l'impression erronée qu'un module n'obtient aucune information de compilation. Ce n'est pas le cas.

Les informations de compilation sont fournies à partir de la configuration au niveau de la suite et seront partagées par tous les modules de la suite. Cela permet une configuration unique de premier niveau pour la suite afin d'exécuter tous les modules qui en font partie.

Par exemple, au lieu que chaque module de la Compatibility Test Suite (CTS) interroge individuellement les informations sur l'appareil, les types, etc., la configuration au niveau de la suite CTS (cts.xml) le fait une seule fois, et chaque module recevra ces informations s'il les demande.

Pour que les objets d'un module reçoivent les informations de compilation, ils doivent procéder de la même manière que dans la configuration Tradefed standard : implémenter l'interface IBuildReceiver pour recevoir l'IBuildInfo. Pour en savoir plus, consultez la section Tests avec un appareil.

Champs de métadonnées

Un grand nombre de modules de test incluent des spécifications metadata, qui ont chacune un objectif unique.

Exemple :

  <option name="config-descriptor:metadata" key="component" value="framework" />
  <option name="config-descriptor:metadata" key="parameter" value="instant_app" />
  <option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
  <option name="config-descriptor:metadata" key="parameter" value="secondary_user" />

Composant

Les métadonnées component décrivent le composant Android général que le module a l'intention de tester. Elles n'ont aucun impact direct sur l'exécution du test. Elles sont principalement utilisées à des fins d'organisation.

La liste à jour des composants autorisés pour CTS est disponible dans CtsConfigLoadingTest. Ce test échoue en cas de pré-commit si un composant inexistant est ajouté à un module CTS.

Vous pouvez filtrer une exécution de suite en fonction des composants à l'aide de module-metadata-include-filter et module-metadata-exclude-filter.

Exemple :

  --module-metadata-include-filter component framework

Cet exemple n'exécute que le module de test annoté avec le composant framework.

Paramètre

Les métadonnées parameter sont fournies à titre informatif et ont un impact sur l'exécution du test. Elles spécifient le mode Android auquel le module de test s'applique. Dans ce cas, les modes sont limités aux modes Android de haut niveau, tels que instant apps, secondary users ou different abis.

Lors de l'exécution de la suite, si le mode s'applique au test, plusieurs variantes du module de test sont créées en fonction du mode. Chaque variante exécute des tests similaires, mais dans des modes différents.

  • instant_app: créez une variante des tests qui installent des APK en tant qu'applications instantanées.
  • multi_abi: créez une variante des tests pour chaque ABI compatible avec l'appareil.
  • secondary_user: créez une variante des tests qui installent des APK et exécutent des tests en tant qu'utilisateur secondaire.

Collecte et post-traitement des métriques pour les modules de test de performances

Pour les modules de test de performances, metrics_collector et metric_post_processor au niveau du module sont autorisés, car ils sont essentiels aux tests de performances. Les collecteurs et post-processeurs de métriques au niveau du module peuvent être spécifiques à un module. Il n'est pas recommandé de spécifier des post-processeurs à la fois au niveau supérieur et au niveau du module.

Une configuration de module de test de performances doit inclure les test-type métadonnées avec la valeur performance, comme suit : xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Sans cela, si une configuration de test inclut metric_collector autre que FilePullerLogCollector ou tout metric_post_processor, le test échoue en cas de pré-commit.

Exemple de configuration de module de test de performances :

<configuration description="Runs sample performance test.">
    <!-- Declare as a performance test module -->
    <option name="config-descriptor:metadata" key="test-type" value="performance" />
    <option name="test-tag" value="hello-world-performance-test" />
    <test class="com.android.tradefed.testtype.HostTest" >
        <option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
    </test>
    <!-- Add module-level post processor MetricFilePostProcessor -->
    <metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
        <option name="aggregate-similar-tests" value="true" />
        <option name="enable-per-test-log" value="false" />
    </metric_post_processor>
</configuration>